https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102982
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to hubicka from comment #4) > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102982 > > > > Richard Biener <rguenth at gcc dot gnu.org> changed: > > > > What |Removed |Added > > ---------------------------------------------------------------------------- > > Status|UNCONFIRMED |NEW > > Keywords| |missed-optimization > > Target Milestone|--- |12.0 > > Ever confirmed|0 |1 > > CC| |hubicka at gcc dot gnu.org, > > | |jamborm at gcc dot gnu.org, > > | |marxin at gcc dot gnu.org > > Last reconfirmed| |2021-10-28 > > Component|tree-optimization |ipa > > > > --- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> --- > > I'd say that's indeed "unfortunate". The main missing optimization though > > is > > treating > > > > c[0][0][0] = 0; > > > > as a "store" when trying to make 'c' constant, not realizing it stores the > > same value as the static initializer (after making it readonly we'd have to > > elide all such stores though). That would fix the testcase as to what > > is likely the desired trigger of the foo() call removal. > > > > Honza/Martin? > > That is probably not too hard to pattern match. One needs a flag in > ipa-ref marking a fact that the store is constant 0 and at IPA time > ignore it for read/write analysis. One catch is that once it becomes > readonly we should optimize out all stores and if we want to play well > with -disable-tree-XYZ we will want specific transform pass for that. fixup_cfg already removes write-only stores so that seems fit for that purpose. Btw, static int x = 1; int main() { x = 1; } should ideally be handled as well as maybe the more common(?) static int x[128]; int main() { memset (x, 0, 128*4); } so we'd like to store a (constant) RHS for the stores in the summaries? (I suppose we cannot selectively stream in a single stmt ;)) > Also if ipa-prop was extended to handle stores/loads to static variables > as "fake arguments" of functions, perhaps we could get this more > systematic. > > Honza
