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

[Matthias Braun via llvm-dev]

> 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>