- User Since
- Sep 29 2018, 11:46 PM (155 w, 6 d)
Oct 1 2020
This looks good to me, but someone who's more familiar with this code should also take a look.
Sep 22 2020
Sep 10 2020
The pre-merge check seems to want markValues instead of MarkValues, even though the method is curretly 'MarkValue'. Should I change this?
Dec 13 2018
We need to resolve this point of disagreement. IMO that optimization is only invalid in regular compilation. I think that for LTO this is a valid optimization. LTO has optimizations that would normally be invalid - for example the Internalize pass.
Nov 27 2018
The point of comdat groups is that only one of the groups of sections from each duplicate comdat set is in linked in from the input files. There are no comdat groups in the output of a normal link (excluding -r links).
Nov 16 2018
so yes the system linker is perfectly legal to remove some parts of a COMDAT group from the final output.
Nov 14 2018
Intuitively, we would not expect comdats in LTO object files as they are not required.
Oct 20 2018
Oct 16 2018
So perhaps this code needs to handle comdat containing an object with associated metadata specially (e.g. could just include in the ExternalComdats set)?
Oct 15 2018
Normally once they are both internalized and removed from the comdat, it shouldn't matter if only one is kept by GlobalDCE. The other is simply an internal function and no longer part of a comdat (so it's not like the comdat is incomplete).
My reading of that commit (D10679), and looking at the code, is that GlobalDCE would be able to remove these members because they should *all* be removed from the comdat by internalization. The change appears to make it such that internalization cannot proceed if any member of the comdat is externally visible and therefore cannot be internalized. If all members of the comdat can be internalized (i.e. not in the ExternalComdats set), then they can all be internalized and the comdat removed from all members.
Oct 13 2018
I accidentally excluded my test cases from the first patch