<div dir="ltr"><br><br><div class="gmail_quote">On Fri, Feb 27, 2015 at 1:38 PM Ahmed Bougacha <<a href="mailto:ahmed.bougacha@gmail.com">ahmed.bougacha@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Feb 26, 2015 at 2:33 AM, Kristof Beyls <<a href="mailto:kristof.beyls@arm.com" target="_blank">kristof.beyls@arm.com</a>> wrote:<br>
><br>
> Hi Ahmed,<br>
><br>
> Did you run these experiments on a platform with a linker that makes<br>
> use of the AArch64CollectLOH-pass-<u></u>produced information?<br>
<br>
As Jim says, I'm on iOS, so yes.  However, I'm mostly running tests<br>
with the pass disabled.<br>
<br>
><br>
> I'm guessing that the AArch64CollectLOH-pass information and a linker<br>
> that makes use of that information could affect the profitability of<br>
> the GlobalMerge pass?<br>
<br>
It could, and does, from what I've seen (beware anecdata):<br>
- reusing the adrp base prevents optimizing it (the various<br>
Adrp*{ldr,str} LOHs).<br>
- reusing the adrp+add MergedGlobal pointer, with indexed addressing,<br>
doesn't prevent the AdrpAdd optimization.<br>
<br>
All in all, whether GlobalMerge is profitable or not (by increasing<br>
register pressure, or adding another indirection), whenever the LOH<br>
optimizations fire, they reduce its usefulness.<br>
<br>
AFAICT, the only case where LOHs help GlobalMerge is when the<br>
MergedGlobal base is closer to the adrp sequence than the actual<br>
global.  Given that we only merge 4k of globals, on a 1MB range this<br>
doesn't happen very often.<br>
<br>
<br>
<br>
Which brings us to my fallback proposal:  what about disabling the<br>
pass on darwin only?  Various darwin-enabled features (e.g., LOHs)<br>
help mitigate the adrp problem, and global usage is usually frowned<br>
upon in those circles (except for singletons, class-/function-statics<br>
and whatnot, which I'm trying to address in an upcoming patch).<br>
<br></blockquote><div><br></div><div>Before making the disabling darwin only I'd like to see some analysis of the regressions/improvements. Has anyone looked at the code for those yet?</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As for other targets, as a first step, making the pass run under -O3<br>
rather than -O1 is hopefully agreeable to everyone?  After all, it is<br>
"aggressive", and isn't always profitable.  That's pretty much the<br>
description of -O3.<br>
We can still run into problematic cases under LTO, though.<br>
<br></blockquote><div><br></div><div>Seems reasonable to me, but probably want to see what happens with the above questions first.</div><div><br></div><div>-eric</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-Ahmed<br>
<br>
><br>
> Thanks,<br>
><br>
> Kristof<br>
><br>
> > -----Original Message-----<br>
> > From: <a href="mailto:llvmdev-bounces@cs.uiuc.edu" target="_blank">llvmdev-bounces@cs.uiuc.edu</a> [mailto:<a href="mailto:llvmdev-bounces@cs.uiuc.edu" target="_blank">llvmdev-bounces@cs.<u></u>uiuc.edu</a>]<br>
> > On Behalf Of Ahmed Bougacha<br>
> > Sent: 26 February 2015 01:13<br>
> > To: LLVM Dev<br>
> > Subject: Re: [LLVMdev] [RFC] AArch64: Should we disable GlobalMerge?<br>
> ><br>
> > With the numbers!<br>
> > -Ahmed<br>
> ><br>
> ><br>
> > On Wed, Feb 25, 2015 at 4:57 PM, Ahmed Bougacha<br>
> > <<a href="mailto:ahmed.bougacha@gmail.com" target="_blank">ahmed.bougacha@gmail.com</a>> wrote:<br>
> > > Hi all,<br>
> > ><br>
> > > I've started looking at the GlobalMerge pass, enabled by default on<br>
> > > ARM and AArch64.  I think we should reconsider that, at least for<br>
> > > AArch64.<br>
> > ><br>
> > > As is, the pass just merges all globals together, in groups of 4KB<br>
> > > (AArch64, 128B on ARM).<br>
> > ><br>
> > > At the time it was enabled, the general thinking was "it's almost<br>
> > > free, it doesn't affect performance much, we might as well use it".<br>
> > > Now, it's preventing some link-time optimizations (as acknowledged in<br>
> > > one of the FIXMEs).<br>
> > ><br>
> > ><br>
> > > -- Performance impact<br>
> > > Overall, it isn't that profitable on the test-suite, and actually<br>
> > > degrades performance on a lot of other - "non-benchmark" - projects I<br>
> > > tried (where the main reason to use a global is file- or function-<br>
> > > static variables, only accessed through a single getter function).<br>
> > ><br>
> > > Across several runs on the entire test-suite, when disabling the pass,<br>
> > > I measured:<br>
> > > without LTO, a -0.19% geomean improvement with LTO, a +0.11% geomean<br>
> > > regression.<br>
> > ><br>
> > > As for just SPEC2006, there are two big regressions: 400.perlbench<br>
> > > (10.6% w/ LTO, 2.7% w/o) and 471.omnetpp (2.3% w/, 3.9% w/o).<br>
> > ><br>
> > > Numbers are attached.<br>
> > ><br>
> > ><br>
> > > -- A way forward<br>
> > > One obvious way to improve it is: look at uses of globals, and try to<br>
> > > form sets of globals commonly used together.  The tricky part is to<br>
> > > define heuristics for "commonly".  Also, the pass then becomes much<br>
> > > more expensive.  I'm currently looking into improving it, and will<br>
> > > report if I come up with a good solution.  But this shouldn't stop us<br>
> > > from disabling it, for now.<br>
> > ><br>
> > > Also, the pass seems like a good candidate for<br>
> > > -O3/CodeGenOpt::Aggressive.  However, the latter is implied by LTO,<br>
> > > which IMO shouldn't include these not-always-profitable optimizations.<br>
> > > That's another problem though.<br>
> > ><br>
> > ><br>
> > ><br>
> > > Right now, I think we should disable the pass by default, until it's<br>
> > > deemed profitable enough.<br>
> > ><br>
> > > -Ahmed<br>
><br>
><br>
><br>
______________________________<u></u>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/llvmdev</a><br>
</blockquote></div></div>