[PATCH 2/7] aarch64: Fix za/zt0 zeroing on function entry

Richard Sandiford rdsandiford@googlemail.com
Sun Apr 19 15:28:00 GMT 2026


Alice Carlotti <alice.carlotti@arm.com> writes:

> On Sat, Apr 18, 2026 at 01:17:38PM +0100, Richard Sandiford wrote:
>> Alice Carlotti <alice.carlotti@arm.com> writes:
>> > Usually if za and zt0 are used privately within a function, then they
>> > are zeroed either by toggling PSTATE.ZA or after committing the lazy
>> > save.  However, if one of za and zt0 is shared, and the other is used
>> > privately, then we need to explicitly zero the private state.
>> >
>> > gcc/ChangeLog:
>> >
>> > 	* config/aarch64/aarch64.cc (aarch64_expand_prologue): Add
>> > 	zeroing of za and zt0 when required.
>> 
>> Is this early enough?  The state transition logic won't see the new
>> writes, so it seems like there's a risk that (say) the zeroing of ZA
>> might not survive some calls.
>
> Oh... because a function with private za state and shared zt0 state
> starts off in the ACTIVE_DEAD state.  I suppose we could patch this up
> for correctness by changing the state on entry to ACTIVE_LIVE in this
> case (and this might be the best fix for stage 4).

That doesn't sound very safe, in that the state would be out of sync
with the liveness set.  Rather than looking for a short-cut, I think
it'd be better to track the state "properly" (as discussed below),
even it that means fixing in stage 1 and backporting.

>> I wonder whether we could instead add new initial states to represent
>> unmet zeroing requirements and add the zeroing when transitioning to
>> the normal internal states?
>
> I've been thinking the same - explicit tracking of known zero state seems
> useful.  I'd like to work out ways to improve this code in stage 1 - or at
> least to improve the documentation and spec so that it doesn't take quite so
> long to understand.

OK.  You seem to have a low opinion of this code...

Richard


More information about the Gcc-patches mailing list