[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.

[Sergey Ostanevich]

Chandler,

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.

Sergos

On Fri, Jul 17, 2015 at 10:02 AM, Gerolf Hoflehner <ghoflehner at apple.com>
wrote:

>
> > On Jul 16, 2015, at 11:48 PM, Chandler Carruth <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
> >
> >
> >
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150722/fc251622/attachment.html>