https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #32 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Jan Hubicka from comment #31) > Having a testcase is great. I was just playing with crafting one. > I am still concerned about value ranges in ipa-prop's jump functions. Maybe my imagination is too limited, but if the ipa-prop's jump functions are computed before ICF is performed, then if you call function a which makes some assumptions about its arguments and SSA_NAMEs used within the function and results in some return range and another one which makes different assumptions and results in a different range, then even if the two functions are merged and either the range info is thrown away or unioned, I think if some functions call one or the other functions then still the original range assumptions still apply, depending on which one actually called. > Let me see if I can modify the testcase to also trigger problem with value > ranges in ipa-prop jump functions. > > Not streaming value ranges is an omission on my side (I mistakely assumed we > do stream them). We ought to stream them, since otherwise we will lose > propagated return value ranges in partitioned programs, which is pity. Not sure if it is a good idea to start streaming them now in stage4, but sure, if we stream them (and I think we should mostly have code to be able to stream that because we can stream the ranges in the jump functions, just unsure about points-to stuff), then I still think best approach would be to merge regardless of range info, but in that case preferrably union instead of throw away. The only question is where to do the merging for the LTO case (where to stream the union of the ranges and where to read it in and update for the SSA_NAMEs).
