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

[Eli Friedman via Phabricator via llvm-commits]

efriedma added a comment.

For call argument registers, we only assign arguments to registers in one place, so it's easy to emit an error message if the IR contains a call which would require a reserved register.  The tricky part would be avoiding spurious error messages.  There are two potential sources of spurious error messages: calls to builtin functions (compiler-rt builtins/memcpy/etc.), and IPO passes which rewrite the calling convention.

For IPO passes, we could disallow rewriting the signature of functions using the C calling convention (so only fastcc functions would get rewritten), and change the calling convention so fastcc functions never use reserved registers.  Only one problem with this: fastcc calls where the caller/callee have different target attributes currently misbehave (see also https://bugs.llvm.org/show_bug.cgi?id=37358 .)

For the builtin functions, not sure what the right solution would be; it gets awkward fast.  If we're expecting that users will only use these for small amounts of code, we might be able to get away with just avoiding calls to builtins in common cases.

In practice, for the kernel's use-case, I think it's unlikely it would actually trigger either of these issues...?  But hard to be sure.

(It's basically impossible to reliably reserve x16 or x17 given the linker constraints.)

----

Looking into it a bit more, I'm not sure -ffixed-x1 is actually what the kernel wants. They don't actually need to reserve the registers, just make them callee-save.  clang has an attribute which can do this in a much more targeted way; see https://clang.llvm.org/docs/AttributeReference.html#preserve-all-clang-preserve-all-clang-preserve-all .


Repository:
  rL LLVM

https://reviews.llvm.org/D48580