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

[Sean Silva via llvm-dev]

On Fri, Sep 23, 2016 at 1:08 PM, Matthias Braun <matze at braunis.de> wrote:

>
> On Sep 23, 2016, at 1:01 PM, Sean Silva via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>
>
> On Tue, Sep 20, 2016 at 10:32 AM, Krzysztof Parzyszek via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> I have posted a patch that switches the API to one that supports this
>> (yet non-existent functionality) earlier:
>> https://reviews.llvm.org/D24631
>>
>> The comments from that were incorporated into the following RFC.
>>
>>
>> Motivation:
>>
>> Certain targets feature "variable-sized" registers, i.e. a situation
>> where the register size can be configured by a hardware switch.  A common
>> instruction set would then operate on these registers regardless of what
>> size they have been configured to have.  A specific example of that is the
>> HVX coprocessor on Hexagon. HVX provides a set of vector registers, and can
>> be configured in one of two modes: one in which vectors are 512 bits long,
>> and one in vectors are 1024 bits in length. The size only determines the
>> number of elements in the vector register, and so the semantics of each HVX
>> instruction does not change: it performs a given operation on all vector
>> elements. The encoding of the instruction does not change between modes, in
>> fact, it is possible to have a binary that runs in both modes.
>>
>> Currently the register size (strictly speaking, "spill slot size") and
>> related properties are fixed and immutable in a RegisterClass. In order to
>> allow multiple possible register sizes, several RegisterClass objects may
>> need to be defined, which then will require each instruction to be defined
>> twice. This is what the HVX code does.  Another approach may be to define
>> several sets of physical registers corresponding to different sizes, and
>> have a large RegisterClass which would be the union of all of them. This
>> could avoid having to duplicate the instructions, but would lead to
>> problems with getting the actual spill slot size or alignment.
>>
>> Since the number of targets allowing this kind of variability is growing
>> (besides Hexagon, there is RISC-V, MIPS, and out of tree targets, such as
>> CHERI), LLVM should allow convenient handling of this type of a situation.
>> See comments in https://reviews.llvm.org/D23561for more details.
>>
>
> 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
>
>
> 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").

-- Sean Silva




> Of course the stuff in here wouldn't hurt for that as it  pushes the code
> into a direction to rely less on well-known/fixed register sizes.
>
> - Matthias
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160923/7daf0d92/attachment.html>