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

[Ahmed Bougacha]

On Thu, Feb 26, 2015 at 1:13 PM, Jiangning Liu <liujiangning1 at gmail.com> wrote:
> 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%

Interesting!  Can you share geomean SPEC2006/2000 numbers, perhaps?

-Ahmed

> 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
>
>