llvm dev - Sep 2016 - RFC: Implement variable-sized register classes

> 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 <mailto: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 <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/D23561
<https://reviews.llvm.org/D23561>for 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
<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. 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/4c861b3b/attachment.html>

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>

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.

In practice, HVX programs are usually compiled for one of the modes. I 
think that the biggest complication in writing dual-mode programs is 
that the application does not have a good way of finding out what mode 
it runs in by querying the hardware (IIRC you need to run in the 
supervisor mode to examine the configuration bit). Another thing is that 
HVX users generally have a specific mode in mind when developing 
programs and being able to run in a different mode is not a high 
priority for them. At least for now...

-Krzysztof

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation