[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.
sergos.gnu at gmail.com
Wed Jul 22 14:37:26 PDT 2015
I'll confirm. After flipping this to 'true' we see regressions are pulled
On Wed, Jul 22, 2015 at 2:02 AM, Gerolf Hoflehner <ghoflehner at apple.com>
> 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>
> 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>
>> > On Jul 16, 2015, at 11:48 PM, Chandler Carruth <chandlerc at gmail.com>
>> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-commits