[llvm-dev] RFC: Implement variable-sized register classes

Matthias Braun via llvm-dev llvm-dev at lists.llvm.org
Fri Sep 23 14:41:36 PDT 2016


> On Sep 23, 2016, at 2:22 PM, Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> On 9/23/2016 3:33 PM, Sean Silva wrote:
>> 
>> 
>> On Fri, Sep 23, 2016 at 1:08 PM, Matthias Braun <matze at braunis.de
>> <mailto:matze at braunis.de>> wrote:
>> 
>> 
>>>    On Sep 23, 2016, at 1:01 PM, Sean Silva via llvm-dev
>>>    <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>>> 
>>>    [...]
>>>    ARM SVE sounds like it will have similar
>>>    issues: https://community.arm.com/groups/processors/blog/2016/08/22/technology-update-the-scalable-vector-extension-sve-for-the-armv8-a-architecture
>>>    <https://community.arm.com/groups/processors/blog/2016/08/22/technology-update-the-scalable-vector-extension-sve-for-the-armv8-a-architecture>
>> 
>>    From glancing over the slides, it seems like SVE has dynamically
>>    sized (i.e. you don't know yet at compile time) registers which
>>    would be a step further than this.
>> 
>> 
>> From what Krzysztof wrote, it sounds like HVX has a similar situation
>> ("it is possible to have a binary that runs in both modes").
> 
> Yes. The instruction and register encodings are identical between the modes. The mode is controlled by a bit in some system configuration register, otherwise the application does not know what mode it works in. Vector loads and stores are indexed in a similar way as in VLA, i.e.
>  vmem(r0+#2) = v0
> will store vector register v0 at the address r0 + 2*VL.

Though I wouldn't expect the spilling (particularily the stackframe layout) code to handle dynamically sized registers properly.

- Matthias


More information about the llvm-dev mailing list