Re: [PATCH 1/7]: SVE: Add CLOBBER_HIGH expression

[Jeff Law <law at redhat dot com>]

On 11/16/2017 05:34 AM, Alan Hayward wrote:
> This is a set of patches aimed at supporting aarch64 SVE register
> preservation around TLS calls.
> 
> Across a TLS call, Aarch64 SVE does not explicitly preserve the
> SVE vector registers. However, the Neon vector registers are preserved.
> Due to overlapping of registers, this means the lower 128bits of all
> SVE vector registers will be preserved.
> 
> The existing GCC code will currently incorrectly assume preservation
> of all of the SVE registers.
> 
> This patch introduces a CLOBBER_HIGH expression. This behaves a bit like
> a CLOBBER expression. CLOBBER_HIGH can only refer to a single register.
> The mode of the expression indicates the size of the lower bits which
> will be preserved. If the register contains a value bigger than this
> mode then the code will treat the register as clobbered.
> 
> The means in order to evaluate if a clobber high is relevant, we need to ensure
> the mode of the existing value in a register is tracked.
> 
> The following patches in this series add support for the CLOBBER_HIGH,
> with the final patch adding CLOBBER_HIGHs around TLS_DESC calls for
> aarch64. The testing performed on these patches is also detailed in the
> final patch.
> 
> These patches are based on top of the linaro-dev/sve branch.
> 
> A simpler alternative to this patch would be to assume all Neon and SVE
> registers are clobbered across TLS calls, however this would be a
> performance regression against all Aarch64 targets.
So just a couple design questions.

Presumably there's no reasonable way to set up GCC's view of the
register file to avoid this problem?  ISTM that if the SVE register was
split into two, one for the part that overlapped with the neon register
and one that did not, then this could be handled via standard mechanisms?

Alternately would it be easier to clobber a subreg representing the high
part of the register?  Hmm, probably not.

Jeff