[patch] follow up on the aarch64 r18 story

[Richard Earnshaw (lists)]

On 07/11/2019 16:16, Olivier Hainque wrote:
> Hello,
> 
> About a year ago we discussed various possibilities regarding
> an issue with the aarch64 selection of r18 as the static chain,
> problematic in environments where the OS uses r18 for "private"
> reasons. VxWorks uses this permission to use r18 as a pointer to
> the current TCB, and Windows does something similar I think.
> 
> I first proposed a change allowing target ports to state that
> r18 should be considered "fixed" and switching the static chain
> to r11 in this case. I had picked r11 as the next after r9/r10
> already used for stack checking,
> 
> After a few exchanges, we agreed that we should rather use r9
> as the alternate static chain and remap the temporary registers
> used for stack-checking to r10/r11.
> 
>    https://gcc.gnu.org/ml/gcc-patches/2018-12/msg01592.html
> 
> We were also thinking that we should be able to change the
> static chain register unconditionally.
> 
> Then during the last GNU cauldron, we realized that libffi
> currently relies on the knowledge of which register is used for
> the static chain, for the support of Go closures.
> 
> Unconditionally changing r18 to something else would break that
> support, most notably on Linux. Adjusting libffi is possible but
> raises a clear compatibility issue.
> 
> The attached patch is a renewed proposal to let target OS
> ports state their private use of r18, switching the static
> chain to r9 and declaring r18 "fixed" in that case.
> 
> In addition to adjusting PROBE_STACK reg values to r10/r11,
> the patch also moves the corresponding definitions together
> with the other special register number definitions, so we have
> a centralized view of the numbering choices.
> 
> This solves the immediate issue for VxWorks (which I'd like
> to contribute) and seems like an interesting thing to have
> in any case, regardless of whether or not we want to more
> generally change the static chain someday.
> 
> With this change, we have good build and testing results
> on both aarch64-elf and aarch64-vxworks7 for a gcc-9 based
> compiler, where only vxworks states TARGET_OS_USES_R18.
> 
> I have also verified that I would build a native aarch64-linux
> mainline compiler with the change and that it still picks r18 as
> the static chain.
> 
> Is this variant ok to commit ?
> 
> Thanks in advance,
> 
> Best Regards,
> 
> Olivier
> 
> 2019-11-07  Olivier Hainque  <hainque@adacore.com>
> 
> 	* config/aarch64/aarch64.h: Define PROBE_STACK_FIRST_REG
> 	and PROBE_STACK_SECOND_REG here, to r10/r11 respectively.
> 	(TARGET_OS_USES_R18): New macro, default value 0 that target
> 	OS configuration files may redefine.
> 	(STATIC_CHAIN_REGNUM): r9 if TARGET_OS_USES_R18, r18 otherwise.
> 	* config/aarch64/aarch64.c (PROBE_STACK_FIRST_REG,
> 	PROBE_STACK_SECOND_REG): Remove definitions.
> 	(aarch64_conditional_register_usage): Preserve r18 if the target
> 	OS uses it, and check that the static chain selection wouldn't
> 	conflict.
> 

My first thought is that if we need a permanent reservation it would be 
better to put this at the top of the list.  r16 and r17 have defined ABI 
uses (for the inter-procedural registers), so that means the next 
highest register is r15.  I'm keen that we avoid, if possible, 
fracturing the space of call clobbered registers by 'just picking 
another one' - if we're not careful we end up with a set of blocked 
holes that just makes life hard for everyone.

Which ever register we eventually settle on, I think this needs to get 
recorded in the ABI docs.  The GO example shows that this is more ABI 
than was previously anticipated.

+/* The pair of scratch registers used for stack probing during 
prologue.  */
+#define PROBE_STACK_FIRST_REG		R10_REGNUM
+#define PROBE_STACK_SECOND_REG		R11_REGNUM
+

These should be moved to the define_constant in aarch64.md that defines 
all the register numbers (add them to near the end of the list where the
other aliases are defined.

R.