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