[PATCH] D41585: [Greedy RegAlloc] Take into account the cost of local intervals when selecting split candidate.

[Marina Yatsina via Phabricator via llvm-commits]

myatsina added a comment.

Hi Quentin,

Sorry it took me a while to get back to you.
I've measure the compile time influence on CTMark for X86 SKL with default compile flags and https://reviews.llvm.org/owners/package/1/, https://reviews.llvm.org/owners/package/2/, https://reviews.llvm.org/owners/package/3/ optimization levels (O0 does not use Greedy RA).
The difference of this patch (and my previous patch regarding the bad evition chains) is between -0.92% and +0.8% for https://reviews.llvm.org/owners/package/1/ and between -0.35% and +0.5% for https://reviews.llvm.org/owners/package/2/, https://reviews.llvm.org/owners/package/3/.
So compile time seems to not be seriously affected by this (or my previous) patch.

Thanks,
Marina



================
Comment at: test/CodeGen/X86/bug26810.ll:28
 ; CHECK-NEXT: ADDPDrr
+; CHECK-NEXT: MOVAPSmr
 ; CHECK-NEXT: ADD32ri8
----------------
qcolombet wrote:
> Why is the new code sequence better?
If we look at the new sequence of the full loop, then it is not worse than the original one.

Here the test is only matching a small part of the loop (because this test is meant to check some other sequence).

Before patch:
==========
loop:
MOVAPSmr
...
SUBPDrr
MOVAPSmr
MOVAPSrm
MULPDrm
ADDPDrr
ADD32ri8
...
jmp loop


After patch:
==========

loop:
...
SUBPDrr
MOVAPSmr
MULPDrm
MOVAPSrm
ADDPDrr
MOVAPSrm
ADD32ri8
...
jmp loop


So the MOVAPSmr which was in the beginning of the loop was moved to the end of the loop.



Repository:
  rL LLVM

https://reviews.llvm.org/D41585