[Bug target/92692] [9/10 Regression] Saving off the callee saved register between ldxr/stxr (caused by shrink wrapping improvements)

[wilco at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92692

--- Comment #5 from Wilco <wilco at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Wilco from comment #3)
> > (In reply to Andrew Pinski from comment #2)
> > > I think this has been a latent bug since revision 243200:
> > >     [AArch64] Separate shrink wrapping hooks implementation
> > > 
> > > I think aarch64_disqualify_components would be a location which should
> > > disqualify the Separate for the register 19.
> > 
> > What is the "exclusives reservation granule" size? It could only fail if the
> > granule is large and the spill happens to be in the same granule as the stxr.
> NO "exclusives reservation granule" does not matter here, please read the
> ARMv8 spec again copied below (B2-142):
> LoadExcl/StoreExcl loops are guaranteed to make forward progress only if,
> for any LoadExcl/StoreExcl loop
> within a single thread of execution, the software meets all of the following
> conditions:
> 1 Between the Load-Exclusive and the Store-Exclusive, there are ****no
> explicit memory accesses****,
> preloads, direct or indirect System register writes, address translation
> instructions, cache or TLB
> maintenance instructions, exception generating instructions, exception
> returns, or indirect branches.
> --- CUT ----
> 
> ****no explicit memory accesses****
> Is a requirement so it does not matter what "exclusives reservation granule"
> size is really.
> We had gone through this beforehand with the ARM architectures and made sure
> that the specifications was worded correctly to the above effect.  The
> wording change happened in 2016.

Well I'm looking at the latest version
(https://static.docs.arm.com/ddi0487/ea/DDI0487E_a_armv8_arm.pdf) where in
figure B2-5 it explicitly states that a store that does not match the
reservation granule on the same CPU must not change the exclusive state.

However if a store does match the granule it is implementation defined, hence
the reason for the text you quote to guarantee forward progress - otherwise a
random store in the loop could accidentally match the exclusive granule and
block progress. However I don't see it saying anywhere that all stores must
clear the exclusive state.