http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48636
--- Comment #15 from Martin Jambor <jamborm at gcc dot gnu.org> 2012-07-03 17:43:35 UTC --- Hi, (In reply to comment #12) > Hi, > I discussed some of the issues today with Martin. For the array descriptor > testcase, we really want ipa-cp to be propagate the constant array bounds > instead of making Inliner to blindly inline enough in all cases. > For that we need > > 1) Make ipa-prop to work on aggregates. For aggregates passed by value we > can have jump functions that define known constants at known offsets I have posted a patch implementing this yesterday: http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00039.html > 2) Make ipa-inline-analysis to produce predicates on constantness of > aggregate fields in the same format I have posted a patch implementing this yesterday too: http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00041.html With this patch, the test case from comment #4 is inlined at -O3 without any parameter tweaking. It is in fact a testcase in that patch. However, functions in real benchmarks are bigger. We will see to what extent IPA-CP can help with them. > 3) Array descriptors are passed by reference, rather than by value. This > need further work, since need to be sure that the value passed does not change > by aliasing. IPA-SRA would help here if it was really SRA and we had > -fwhole-program, but that is weak. We would need IPA-PTA to solve this in > general. Perhaps frontend could help us here since the descriptors are > probably > constant after they are initialized, or is there way to change existing > descriptor? At the moment I'm relying on a slightly sophisticated intra-PTA and TBAA. I'll try to investigate where this does not work in Fortran and perhaps will have some suggestions afterwards. > 4) Make ipa-inline-analysis to understand that determining loop bounds is > very cool to do. Yep, knowing what constants should get a profitability "boost" would be indeed very beneficial. Meanwhile, the following patch also helps ipa-inline-analysis.c with cases like fatigue2: http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00052.html
