[PATCH] D48580: [AArch64] Support reserving x1-7 registers.

[Tri Vo via Phabricator via llvm-commits]

trong added a comment.

Making registers callee-saved for CONFIG_ARM64_LSE_ATOMICS regresses kernel performance since it results in extra save/restores of argument registers. So for performance it's preferable to use -ffixed-x[1-7].

GCC implementation of -ffixed does not alter the calling convention, i.e. function calls use x0-x7 as argument registers regardless of -ffixed- flags. The flags prevent allocation of those registers. Linux kernel code relies on this behavior, e.g. https://github.com/torvalds/linux/blob/master/arch/arm64/lib/Makefile#L14. atomic_ll_sc.o is built with -ffixed-x[1-7], but its callers are not.

IIUC, miscompilation can happen if caller and callee have different sets of reserved registers. In this case we should emit a warning (not an error) since the user is expected handle such cases, e.g. kernel code https://github.com/torvalds/linux/blob/master/arch/arm64/include/asm/atomic_ll_sc.h

As efriedma pointed out, clang can (already does?) express -ffixed- flags as function attributes `"target-features"="+reserve-x1". So it should be possible to issue appropriate warnings during link time.

Kernel maintainers prefer if clang supported -ffixed flags for theirs use case. https://www.spinics.net/lists/arm-kernel/msg671434.html

Is it reasonable to implement -ffixed-x[0-7] flags for argument registers without changing calling convention and emitting warnings when caller/callee have different set of reserved registers? Afterwards, we could generalize to other aarch64 GPRs. Then we could implement a more general attribute, which I imagine shouldn't be too difficult since IR already has a representation for reserved registers.


Repository:
  rL LLVM

https://reviews.llvm.org/D48580