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

Krzysztof Parzyszek via llvm-dev llvm-dev at lists.llvm.org
Fri Sep 23 14:22:03 PDT 2016

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


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

More information about the llvm-dev mailing list