This is an archive of the discontinued LLVM Phabricator instance.

[Sparc] Give the option to use the OS reserved global registers
Needs ReviewPublic

Authored by dcederman on Aug 14 2018, 2:22 AM.



The g5, g6, and g7 registers can be used as temporary registers in generic code if they are not reserved for a specific usage by the OS or system libraries. This can for example be the case when compiling for a bare metal system or when compiling the OS kernel. In GCC the corresponding option is called -fcall-used-g[5,6,7] and is used when compiling the Linux kernel.

The code is simplified by using markSuperRegs() that also reserves the corresponding covering register pairs when needed.

Diff Detail

Event Timeline

dcederman created this revision.Aug 14 2018, 2:22 AM

I generally cringe at these sorts of register-use-changing-flags, but SPARC has basically explicitly defined all of G2-G7 as fixed-usage or scratch registers as the user/system desires. And these registers don't participate in the calling convention (not args or return values, and aren't saved), it's not completely terrible. Only G7 is ever used for anything by the compiler, to implement TLS.

Some general comments:

  1. G2-G4 should also be handled the same way, and the existing internal command-line-flag hack removed.
  2. Should be careful of the usage of %g7 -- the TLS emission functions should error out when G7 is declared as a scratch register -- it doesn't make sense to try to use it as a thread register at the same time.
  3. SparcAsmPrinter::EmitFunctionBodyStart should be updated to annotate usage of the registers appropriately.

I find this name unclear. I'd suggest having a set of fields named "ReserveRegG5" etc. (that is: with the opposite sense).

Added attributes to prevent %g2-%g5 from being used as scratch register or to allow the use of %g5-%g7 as scratch registers. %g5 is reserved by default for 32-bit but not for 64-bit.

Renamed the field names to ReserveRegG*.

Added error messages if the TLS model or stack protector tries to use %g7 and it is not reserved.

EmitFunctionBodyStart now checks the list of actually reserved registers to output the correct register annotations.

jyknight added inline comments.Oct 9 2018, 8:22 AM

Having some use 'reserve', and some use 'use' seems unfortunate. If, instead, they're all spelled "reserve-reg-*", but the features for G5 (sometimes), G6, and G7 are enabled by default, I *think* it would then be possible to disable them with "target-features"="-reserve-reg-g5".

dcederman added inline comments.Oct 15 2018, 2:11 AM

Agreed. I did it like that to avoid having to add the features to each processor definition. But now I see on other targets that it is OK to extend the feature string in initializeSubtargetDependencies, so I'll take that approach.

dcederman updated this revision to Diff 169661.Oct 15 2018, 2:15 AM

Removed the UseRegG* features and enabled the ReserveRegG6, ReserveRegG7, and ReserveRegG5 (on 32-bit) features by default.

Any other comments @jyknight , or does it look ok?