[Bug target/85434] Address of stack protector guard spilled to stack on ARM

["thopre01 at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #3 from Thomas Preud'homme <thopre01 at gcc dot gnu.org> ---
(In reply to Thomas Preud'homme from comment #2)
> (In reply to Thomas Preud'homme from comment #1)
> > This is caused by missing stack_protect_set and stack_protect_test pattern
> > in ARM backend. It would be nice though if the address could be marked such
> > that it doesn't go on the stack to have the default implementation a bit
> > more robust. It might be worth having a warning if the override is not done
> > as well.
> 
> Nope sorry, the address is put in a register before the test pattern is
> called.

This happens when expanding the tree that holds the guard's address. It's a
symbol_ref for which the default expand code of loading into a register is
used. This happens also for AArch64 and I suspect for x86 as well.

What makes it worse on ARM is that cse_local sees 2 SET instructions computing
the address of the guard and reuse the register being set in the first
instruction instead of recomputing again. Because of the distance between that
first SET and the comparison between guard and canari the chances of getting
the address spilled are higher. This does not happen for AArch64 because the
mov of symbol_ref generates an UNSPEC of a memory address whereas ARM generates
a MEM of an UNSPEC symbol_ref. However I suppose with scheduling it's possible
for the set of guard address and following test of guard against canari to be
moved apart and spill to happen in theory.

My feeling is that the target patterns should also do the address computation,
ie stack_protect_set and stack_protect_test would take that MEM of symbol_ref
instead of expanding it first.

Thoughts?