[PATCH] D11213: [PM/AA] Disable the core unsafe aspect of GlobalsModRef in the face of basic changes to the IR such as folding pointers through PHIs, Selects, integer casts, store/load pairs, or outlining.
ghoflehner at apple.com
Tue Jul 21 16:02:07 PDT 2015
There is at least a 3% regression on CINT2006/403.gcc. I guess this suggests there is enough evidence that the preferred default setting should be ‘true’ .
> On Jul 21, 2015, at 2:48 PM, Sergey Ostanevich <sergos.gnu at gmail.com> wrote:
> We seen a number of regressions across EEMBC 1.1, 2.0 and SPEC 2000, 2006 tests using "-Ofast -flto -funroll-loops -mfpmath=sse" with targets "slm" and "core-avx2".
> Will try to work out some small test case.
> On Fri, Jul 17, 2015 at 10:02 AM, Gerolf Hoflehner <ghoflehner at apple.com <mailto:ghoflehner at apple.com>> wrote:
> > On Jul 16, 2015, at 11:48 PM, Chandler Carruth <chandlerc at gmail.com <mailto:chandlerc at gmail.com>> wrote:
> > chandlerc marked 2 inline comments as done.
> > chandlerc added a comment.
> > Thanks Pete and Gerolf!
> > Based on Pete's review and some benchmark results Michael Z shared that show very limited impact of GlobalsModRef on performance, I'm submitting this as is. If folks *do* end up seeing regressions, by all means follow up here or on the commit thread and we can try other defaults, etc.
> > ================
> > Comment at: lib/Analysis/IPA/GlobalsModRef.cpp:56
> > @@ +55,3 @@
> > +static cl::opt<bool> EnableUnsafeGlobalsModRefAliasResults(
> > + "enable-unsafe-globalsmodref-alias-results", cl::init(false));
> > +
> > ----------------
> > Gerolf wrote:
> >> My preference for default is 'true'. Innocent until proven guilty - with test case counting as a proof. If performance data is in the noise I will switch my preference.
> > Michael Z got spec2k6 (and some other benchmarks) and some other numbers with GlobalsModRef completely disabled and the changes were in the noise, so I'm going with the default of false based on this comment.
> Not sure. My understanding from earlier today was that were some issues with the runs that still need to be resolved.
> > However, if you or anyone else gets performance data that is *not* in the noise, just shout, and I'm happy to flip this the other way. =]
> Sounds great! But in case there is a loss the best outcome might be a small test case so we can brainstorm the best way to recover it.
> > http://reviews.llvm.org/D11213 <http://reviews.llvm.org/D11213>
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu <mailto:llvm-commits at cs.uiuc.edu>
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits <http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-commits