[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