[llvm-dev] [GlobalISel][AArch64] Toward flipping the switch for O0: Please give it a try!

[Quentin Colombet via llvm-dev]

Great!
I thought I had to look at our pipeline at O0 to make sure optimized regalloc was supported (https://bugs.llvm.org/show_bug.cgi?id=33022 <https://bugs.llvm.org/show_bug.cgi?id=33022> in mind). Glad I was wrong, it saves me some time.

> On May 22, 2017, at 12:51 AM, Kristof Beyls <kristof.beyls at arm.com> wrote:
> 
> 
>> On 22 May 2017, at 09:09, Diana Picus <diana.picus at linaro.org> wrote:
>> 
>> Hi Quentin,
>> 
>> I actually did a run with -mllvm -optimize-regalloc -mllvm
>> -regalloc=greedy over the weekend and the test does pass with that.
>> Haven't measured the compile time though.
>> 
>> Cheers,
>> Diana
> 
> I also did my usual benchmarking run with the same options as Diana did above:
> - Comparing against -O0 without globalisel: 2.5% performance drop, 0.8% code size improvement.

That’s compared to 9.5% performance drop and 2.8% code size regression, without that regalloc scheme, right?

> - Comparing against -O0 without globalisel but with the above regalloc options: 5.6% performance drop, 1% code size drop.
> 
> In summary, the measurements indicate some good improvements.
> I also haven't measure the impact on compile time.

Do you have a mean to make this measurement?
Ahmed did a bunch of compile time measurements on our side and I wanted to see if I need to put him on the hook again :).

> 
> Doing a few quick spot checks on the generated code, I still see some constants being created in the entry BB and stored on the stack.

Feel free to file PRs if you think that shouldn’t happen.

@Eric, how does it look on your side?

Cheers,
-Quentin

> I haven't tried to investigate if the entry BB seems like a good place to materialize those remaining constants.
> 
> Thanks,
> 
> Kristof

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170523/712751b4/attachment.html>