Open mstorsjo opened 2 months ago
I'll go ahead and revert https://github.com/llvm/llvm-project/commit/601645c3b70e2a17d18779a3a51b8bc9ecdc9aa6, as it indeed wasn't NFC as intended.
Reverted in 0cf4cb4bde440586c310554d93dc09e47cb9bb79.
Right, this should be "has comdats, but is not COFF", and that covers mingw. I think the predicate this code wants is more like "are comdat groups supported". COFF supports associativity, which is different, but we model it with groups because I thought that was a good idea ~9 years ago.
Since 601645c3b70e2a17d18779a3a51b8bc9ecdc9aa6, CC @rnk, the following testcase fails:
main.cpp:
lib.cpp:
stub.c:
To reproduce:
The reason for this is visible, if we inspect the output of the LTO compile:
So due to the
-mguard=cf
, we end up keeping a reference to__cxx_global_var_init
in the.gfids$y
section - but the LTO optimization itself has decided to optimize out the__cxx_global_var_init
function entirely.It seems like the exact ordering of object files is crucial here; if I swap the order of
lib.o
andmain.o
in this example, thenout.exe.lto.main.s
does retain the__cxx_global_var_init
function, butout.exe.lto.lto.s
has lost the function instead.This was originally reported downstream at https://github.com/mstorsjo/llvm-mingw/issues/457.
Debugging what really happens during the LTO compilation is somewhat finicky; if I grab the LTO IR with
-lldemit:llvm -out:lto.bc
and try to compile that withllc
, I get different results as well. (In that case, I end up with an undefinedGetUnused()
function.)As the referenced commit 601645c3b70e2a17d18779a3a51b8bc9ecdc9aa6 was NFCI, no functional changes intended, but we do have functional changes here, I think it would be reasonable to revert the commit.