Commit 728cc0075e5dfdb454ebe6418b63bdffae71ec14 made comdat symbols
from LTO objects be treated as any regular comdat symbol. This works
great for symbols that actually are IMAGE_COMDAT_SELECT_ANY, but
if e.g. the symbols have a less trivial selection type, like
IMAGE_COMDAT_SELECT_SAME_SIZE, we can't check that between the plain
symbol from the bitcode file (before actually doing the LTO compilation)
and other regular object files.
Therefore bring back one aspect of handling from before; that comdat
resolution with a leader from an LTO symbol is essentially skipped,
like it was before 728cc0075e5dfdb454ebe6418b63bdffae71ec14.
Or is there any better way of including the info about the kind of
symbol for the leader? Previously we could check leader->data to see
if it was a regular or LTO symbol. Overall we'd of course want to make
LTO cases behave more like regular symbols, but for this aspect, I
don't think we practically can?
Can this be simplified a bit to merge declaration and assignment? Maybe something like:
I'm not 100% sure that is the same, but there's something there.
Actually, maybe the simplest way to recover the old behavior is to check isa<BitcodeFile>(leader->file). Then a new COMDATType isn't needed. Does that work?