[LLVMdev] [RFC] AArch64: Should we disable GlobalMerge?

[Jiangning Liu]

Hi Ahmed,

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.

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)

spec.cpu2000.ref.253_perlbmk 3.27%
spec.cpu2000.ref.254_gap 3.18%

although I do see some improvements like below, (negative is good)

spec.cpu2006.ref.400_perlbench -1.90%
spec.cpu2006.ref.471_omnetpp -1.64%
spec.cpu2006.ref.482_sphinx3 -1.03%

Thanks,
-Jiangning


2015-02-26 20:09 GMT+08:00 Renato Golin <renato.golin at linaro.org>:

> On 26 February 2015 at 00:57, Ahmed Bougacha <ahmed.bougacha at gmail.com>
> wrote:
> > -- A way forward
> > One obvious way to improve it is: look at uses of globals, and try to
> > form sets of globals commonly used together.  The tricky part is to
> > define heuristics for "commonly".  Also, the pass then becomes much
> > more expensive.  I'm currently looking into improving it, and will
> > report if I come up with a good solution.  But this shouldn't stop us
> > from disabling it, for now.
>
> Hi Ahmed,
>
> Before "moving forward", it would be good to understand what in
> GlobalMerge is impacting what in LTO.
>
> With LTO becoming more important nowadays, I agree we have to balance
> the compiler optimisations to work well with it, but by turning things
> off we might be impacting unknown code in an unknown way.
>
> We'll never know how unknown code behaves, but if at least we
> understand what of GM affects what of LTO, then people using unknown
> code will have a more informed view on what to disable, when.
>
> cheers,
> --renato
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150227/9f87ea2d/attachment.html>