[PATCH] D26648: Clarify semantic of reserved registers.

[Quentin Colombet via llvm-commits]

> On Nov 14, 2016, at 6:48 PM, Matthias Braun <matze at braunis.de> wrote:
> 
> The more I think about it, the more I feel uneasy about the disconnect between the effecitve register reserving via allocation orders and the registers actually reported as reserved. Did you check for example whether the commit below works correctl with the RegisterScavenger?

No I haven’t, and I am actually pretty sure it does not use the allocation order as you suspect :).
This is not a correctness problem and if we need the scavenger I guess we are already in a bad situation performance wise. Anyhow, I’d say this is orthogonal, we can improve the scavenger later, but I believe having a clear semantic is best.

Cheers,
-Quentin

> I am pretty sure scavengeRegister() will pick any free register it finds and diregard the allocation order.
> 
> - Matthias
> 
>> On Nov 14, 2016, at 6:40 PM, Quentin Colombet <qcolombet at apple.com <mailto:qcolombet at apple.com>> wrote:
>> 
>> I prefer the hard rule to be fair, i.e., the semantic would be easier to understand.
>> 
>> Q.
>>> On Nov 14, 2016, at 6:33 PM, Matthias Braun <matze at braunis.de <mailto:matze at braunis.de>> wrote:
>>> 
>>> That would work.
>>> 
>>> Alternatively we could drop the super-reg being reserved as a hard rule and only recommend it. We could provide the verifier in a function that targets can optionally call, mips just wouldn’t do that then.
>>> 
>>> - Matthias
>>> 
>>>> On Nov 14, 2016, at 6:25 PM, Quentin Colombet <qcolombet at apple.com <mailto:qcolombet at apple.com>> wrote:
>>>> 
>>>> ARM has a similar problem and we solved it with “fancy” allocation order:
>>>> commit 8927f6cd0f8d7614e8682a2da08f0a9769be9603
>>>> Author: Tim Northover <tnorthover at apple.com <mailto:tnorthover at apple.com>>
>>>> Date:   Mon Aug 3 17:20:10 2015 +0000
>>>> 
>>>>     ARM: prefer allocating VFP regs at stride 4 on Darwin.
>>>>     
>>>>     This is necessary for WatchOS support, where the compact unwind format assumes
>>>>     this kind of layout. For now we only want this on Swift-like CPUs though, where
>>>>     it's been the Xcode behaviour for ages. Also, since it can expand the prologue
>>>>     we don't want it at -Oz.
>>>>     
>>>>     git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243884 <https://llvm.org/svn/llvm-project/llvm/trunk@243884> 91177308-0d34-0410-b5e6-96231b3b80d8
>>>> 
>>>>> On Nov 14, 2016, at 6:15 PM, Matthias Braun <matze at braunis.de <mailto:matze at braunis.de>> wrote:
>>>>> 
>>>>> MatzeB added a reviewer: sdardis.
>>>>> MatzeB added a comment.
>>>>> 
>>>>> These new rules break existing use in Mips :-(
>>>>> 
>>>>> Mips has 32bit floatregs F0-F31, each pair forms a double reg (F0+https://reviews.llvm.org/F1=D0 <f0+https://reviews.llvm.org/F1=D0>, https://reviews.llvm.org/F2+https://reviews.llvm.org/F3=https://reviews.llvm.org/D1 <https://reviews.llvm.org/F2+https://reviews.llvm.org/F3=https://reviews.llvm.org/D1>, ...). There is an option in the mips backend that aims at disabling the odd F registers, so 32bit float values only end up in F0, https://reviews.llvm.org/F2 <https://reviews.llvm.org/F2>, https://reviews.llvm.org/F4 <https://reviews.llvm.org/F4>, ... In this case it is actually expected that the register allocator still assigns the D0-D15 as usual even though the would indirectly use https://reviews.llvm.org/F1,https://reviews.llvm.org/F3 <https://reviews.llvm.org/F1,https://reviews.llvm.org/F3>,...
>>>>> 
>>>>> Is there another way to handle this in the mips target?
>>>>> 
>>>>> 
>>>>> Repository:
>>>>>  rL LLVM
>>>>> 
>>>>> https://reviews.llvm.org/D26648 <https://reviews.llvm.org/D26648>
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161114/7b6f9d3e/attachment.html>