https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107833
--- Comment #13 from rguenther at suse dot de <rguenther at suse dot de> --- On Fri, 2 Dec 2022, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107833 > > --- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > So, do we whack-a-mole in this case some more and try harder in > mark_ssa_maybe_undefs > by basically repeating the CCP4 UNDEFINED propagation, or invent some new stmt > or marking that IVOPTS could use before the loop to turn possibly undefined > into undefined but always the same random pattern within the same invocation > (kind of like asm ("" : "+g" (undef));), or something else (like after IVOPTS > stop the UNDEFINED propagation on loop header PHIs or something similar)? Given the implementation of mark_ssa_maybe_undefs we can either blame (and fix) invariant motion (-fno-tree-loop-im fixes the testcase as well) or remove the ssa_name_any_use_dominates_bb_p check in this function, marking more SSA names as possibly undefined. We can also choose to ignore the issue until we run into this in the real world or try to design something better here (I keep being pointed at LLVM here but I don't see them solving the issue either). I will see whether I can make invariant motion not hoist undefined names.
