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

[Sean Silva via llvm-dev]

On Fri, Sep 23, 2016 at 2:22 PM, Krzysztof Parzyszek <
kparzysz at codeaurora.org> wrote:

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


Although it is sort of hacky, one could zero a block of memory and then see
where `vmem(r0+#2) = v0` ends up (making sure that v0 is all 1's for
example).


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


At least in the ARM SVE case, it seems like VLA could maybe be useful for
big.LITTLE arrangements where the big cores may have wider vector width.
That may not be possible in practice actually (would need program
restrictions on how it relies on the vector length so that when a core
migration little<->big you would have to paper over the VL change (e.g. big
core can run temporarily in a "narrow" mode maybe?); that's a bit
hand-wavey... not sure it would actually work)

-- Sean Silva


>
>
> -Krzysztof
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
> by The Linux Foundation
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160926/cc447acd/attachment.html>