[llvm-dev] Disable spilling sub-registers in LLVM

[ahmede via llvm-dev]

To make my point clear, I believe an implementation of 
storeRegToStackSlot()/loadRegFromStackSlot() is not sufficient (as it 
received the physical register already). Does this make sense?

On 2018-01-30 13:33, ahmede wrote:
> Right Matthias, I am aware that an implementation for
> storeRegToStackSlot()/loadRegFromStackSlot() is necessary. But these
> functions receive the physical register that need to be spilled, they
> might receive the sub-register. In this case, using the super-register
> naively is unsafe (e.g., one might overwrite parts of it). Thus, I
> think the register allocator/spillar need to be aware of the exact
> register that is spilled.
> 
> 
> 
> On 2018-01-30 13:23, Matthias Braun wrote:
>> I still think my answer applies that you have to modify
>> storeRegToStackSlot()/loadRegFromStackSlot(). They decide how
>> registers are spilled and reloaded. Nobody is stopping you from using
>> super registers spills/reloads to implement spilling/reloading smaller
>> registers there.
>> 
>> - Matthias
>> 
>>> On Jan 30, 2018, at 10:21 AM, ahmede <ahmede at ece.ubc.ca> wrote:
>>> 
>>> Hi Quentin,
>>> 
>>> Let me clarify if I understood this correctly.
>>> 
>>> If the accesses (writes and reads) to sub-registers are expressed 
>>> always as sub-registers of the super-register register class (e.g., 
>>> SuperReg.sub1;), then the spilling decision is for the super 
>>> register.
>>> 
>>> But, if the accesses are in terms of the register class of the 
>>> sub-registers directly (SubReg;), then the spilling decision will be 
>>> for the sub-register.
>>> 
>>> 
>>> So if we forced before register allocation all sub-register accesses 
>>> to be accessed to "lanes" of the super register class then we 
>>> guarantee that spilling is for the Super Registers only?
>>> 
>>> Thanks,
>>> Ahmed
>>> 
>>> 
>>> On 2018-01-30 00:22, Quentin Colombet wrote:
>>>> Hi Ahmed,
>>>> If you access your values with sub-registers indices, IIRC the 
>>>> inline
>>>> spiller will spill the super register.
>>>> If you access your values directly (via sub-regclass), then the
>>>> spiller uses this class.
>>>> Basically what I am saying is the spiller spills the value that
>>>> contains the accesses.
>>>> E.g.,
>>>> = v; will spill v
>>>> = v.sub1; will spill v too, but v is a super register in that case.
>>>> Cheers,
>>>> -Quentin
>>>>> On Jan 29, 2018, at 6:38 PM, ahmede via llvm-dev 
>>>>> <llvm-dev at lists.llvm.org> wrote:
>>>>> Hi Matthias,
>>>>> No. I want the register allocator to spill the super-register (the 
>>>>> large one e.g., 64-bit) and not just the sub-register (e.g., the 
>>>>> 32-bit that is a piece of of the 64-bit register) because the stack 
>>>>> loads/store width is 64-bit in this example.
>>>>> RegClass1   (sub-registers):  sub_registers (32-bit)               
>>>>> --> can be natively used in arithmetic operations but no stack 
>>>>> loads/stores for that width.
>>>>> RegClass2 (super-registers):  [sub_register, subregister] (64-bit)  
>>>>> --> can be natively used in arithmetic operations and can be used 
>>>>> in loads/stores.
>>>>> Thanks,
>>>>> Ahmed
>>>>> On 2018-01-29 20:20, Matthias Braun wrote:
>>>>>>> On Jan 29, 2018, at 1:20 PM, ahmede via llvm-dev 
>>>>>>> <llvm-dev at lists.llvm.org> wrote:
>>>>>>> Hi,
>>>>>>> I wonder if there is a way in LLVM to disable spilling a 
>>>>>>> register-class while still enabling the super-registers of this 
>>>>>>> register-class to be spilled.
>>>>>> What would you have the register allocator do when it runs out of
>>>>>> register and you have spilling disabled? Abort the compilation?
>>>>>> If you just want a special instruction sequence (like using a 
>>>>>> bigger
>>>>>> loads/stores for the spills) then you should be able to implement 
>>>>>> that
>>>>>> in storeRegToStackSlot()/loadRegFromStackSlot().
>>>>>> - Matthias
>>>>>>> If not, how can we implement spilling for sub-registers when 
>>>>>>> stack load/stores can only operate on the super registers? Is 
>>>>>>> there a way even if it is suboptimal?
>>>>>>> Thanks,
>>>>>>> Ahmed
>>>>>>> _______________________________________________
>>>>>>> LLVM Developers mailing list
>>>>>>> llvm-dev at lists.llvm.org
>>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>> _______________________________________________
>>>>> LLVM Developers mailing list
>>>>> llvm-dev at lists.llvm.org
>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev