<div dir="ltr"><br><br><div class="gmail_quote">On Fri, Feb 27, 2015 at 2:13 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 Fri, Feb 27, 2015 at 1:42 PM, Eric Christopher <<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>> wrote:<br>
><br>
><br>
> On Fri, Feb 27, 2015 at 1:38 PM Ahmed Bougacha <<a href="mailto:ahmed.bougacha@gmail.com" target="_blank">ahmed.bougacha@gmail.com</a>><br>
> wrote:<br>
>><br>
>> 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>><br>
>> 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>
><br>
> Before making the disabling darwin only I'd like to see some analysis of the<br>
> regressions/improvements. Has anyone looked at the code for those yet?<br>
<br>
Yep, I put a quick analysis in my other reply.<br></blockquote><div><br></div><div>The LOH/ADRP bit?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
><br>
>><br>
>> 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>
><br>
> Seems reasonable to me, but probably want to see what happens with the above<br>
> questions first.<br>
<br>
Fair enough.  Bottom line is:<br>
- disabling it without LTO is a slight win on the test-suite, a solid<br>
win everywhere else I've looked.<br>
- disabling it with LTO regresses quite a few SPEC benchmarks, and is<br>
overall a slight regression on the test-suite.<br>
<br></blockquote><div><br></div><div>Ah, I meant an analysis of the code, not just the numbers. I think the ADRP/LOH commentary really helps. It might only be a decent LTOish optimization, but I'm still curious how it's helping there over other optimizations.</div><div><br></div><div>Anyhow, FWIW I'm in favor of pulling it out of the non-LTO pipeline universally.</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>
> -eric<br>
><br>
</blockquote></div></div>