This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On November 16, 2017 7:05:30 PM GMT+01:00, Jeff Law <law@redhat.com> wrote:
>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.

I thought of a set of the preserved part to itself that leaves the upper part undefined. Not sure if we have such thing or if it would work in all places that a clobber does.

Richard. 

>Jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]