https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
--- Comment #19 from Jan Hubicka <hubicka at ucw dot cz> --- > Note I didn't check if it helps the testcase .. I will check. > > > > > > > A "nicer" solution might be to add a informational operand > > > to TARGET_MEM_REF, representing the base pointer to be used for > > > alias/points-to purposes. But if that's not invariant it might > > > keep some otherwise unnecessary definition stmts live. > > > > Yep, I see that forcing extra IV to track original semantics would be > > trouble here. I think that after iv-opts we should be done with more > > fancy propagation across loops. > > > > However, to avoid ipa-modref summary degradation, perhaps scheduling the > > pass before ivopts would make sense... > > We also have that other bug where store-merging breaks the IPA summary > which gets prevailed in the late modref, so moving it around doesn't > solve all of the IL related issues ... I did not mean to paper around the fact that we produce wrong code with TARGET_MEM_REFs (we ought to fix that). If ivopts makes it difficult to track bases of memory accesses, we may get better summaries if we built them earlier. The purpose for late mod-ref is to analyze the function body as cleaned up as possible (so we do not get confused i.e. by dead memory accesses and other stuff we see before inlining) but we do not want to lower the representation too much, since that is generally lossy too. I will look at the store merging issue. Honza
