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

[ahmede via llvm-dev]

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