<div dir="ltr"><span style="font-size:13.63636302948px">Hi Ahmed,</span><br><div><span style="font-size:13.63636302948px"><br></span></div><div><span style="font-size:13.63636302948px">Yes. I'd share with Kristof and Renato's concerns, and the impact/dependence upon link-time tool should be clarified before disabling this pass.</span></div><div><span style="font-size:13.63636302948px"><br></span></div><div><span style="font-size:13.63636302948px">On the other hand, actually the test on our hardware shows disabling this pass without LTO considered, some spec benchmarks would have big regressions, (positive is bad)</span></div><div><span style="font-size:13.63636302948px"><br></span></div><div><div style><font>spec.cpu2000.ref.253_perlbmk<span class="" style="white-space:pre"> </span>3.27%<span class="" style="white-space:pre"> </span></font></div><div style><font>spec.cpu2000.ref.254_gap<span class="" style="white-space:pre"> </span>3.18%</font></div></div><div style><font><br></font></div><div style><font>although I do see some improvements like below, (negative is good)</font></div><div style><font><br></font></div><div>spec.cpu2006.ref.400_perlbench<span class="" style="white-space:pre"> </span>-1.90%</div><div>spec.cpu2006.ref.471_omnetpp<span class="" style="white-space:pre"> </span>-1.64%</div><div style>spec.cpu2006.ref.482_sphinx3<span class="" style="white-space:pre"> </span>-1.03%<font> </font></div><div><span style="font-size:13.63636302948px"><br></span></div><div><span style="font-size:13.63636302948px">Thanks,</span></div><div><span style="font-size:13.63636302948px">-Jiangning</span></div><div><span style="font-size:13.63636302948px"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-02-26 20:09 GMT+08:00 Renato Golin <span dir="ltr"><<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 26 February 2015 at 00:57, Ahmed Bougacha <<a href="mailto:ahmed.bougacha@gmail.com">ahmed.bougacha@gmail.com</a>> wrote:<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>
</span>Hi Ahmed,<br>
<br>
Before "moving forward", it would be good to understand what in<br>
GlobalMerge is impacting what in LTO.<br>
<br>
With LTO becoming more important nowadays, I agree we have to balance<br>
the compiler optimisations to work well with it, but by turning things<br>
off we might be impacting unknown code in an unknown way.<br>
<br>
We'll never know how unknown code behaves, but if at least we<br>
understand what of GM affects what of LTO, then people using unknown<br>
code will have a more informed view on what to disable, when.<br>
<br>
cheers,<br>
--renato<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">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/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br></div>