On Tue, 12 Mar 2024, Jakub Jelinek wrote: > On Tue, Mar 12, 2024 at 05:21:58PM +0100, Jakub Jelinek wrote: > > On Tue, Mar 12, 2024 at 10:46:42AM +0100, Jan Hubicka wrote: > > > I am sorry for delaying this. I made the variant that simply compares > > > value range of functions and prevents merging if they diverge and wanted > > > to make some bigger statistics. This made me notice some performance > > > problems on clang performance and libstdc++ RB-trees which disrailed me > > > from the original PR. I will finish the statistics today. > > > > With the posted patch, perhaps if we don't want to union jump_tables etc., > > all we could punt on is differences in the jump_table VRs rather than just > > any SSA_NAME_RANGE_INFO differences. > > To expand on this, I think we need to either union or punt on jump_func > differences in any case, because for LTO we can't really punt on > SSA_NAME_RANGE_INFO differences given that we don't stream that out and in. > So the ipa_jump_func are I think the only thing that actually can differ > on the ICF merging candidates from value range POV.
I agree. Btw, I would have approved the original patch in this thread that wipes SSA_NAME_INFO in merged bodies to mimic what LTO effectively does right now. That also looks most sensible to backport. But I'll defer to Honza in the end (but also want to point out we need something suitable for backporting). Richard.
