[PATCH] D145131: [Arm][AArch64] Setting IsX18ReservedByDefault() to true for Unknown OSes

Thu Mar 2 08:53:09 PST 2023

DavidSpickett added a comment.

> Doesn't this imply x18 should be reserved by default unless they change the default to use it?

No. That text is mostly about building your platform independent source code, in the right way for the platform that will run it. That's why it highlights hand written assembly. You can easily tell a compiler to not use x18, but you can't make it translate x18 uses in inline assembly or assembly source files.

> Thank you for the explanation regarding the current constraint that "unknown" includes in particular "bare metal". Do you think that it would make sense going forward to start distinguishing between "bare metal" and "unknown"? After all, knowing that the target is "bare metal" is information in its own right, and here it enables using x18.

I disagree with this because as soon as some unknown platform wants to break from what clang has decided the default should be, we will have to add a bunch of options to subtract parts of it.

The ABI already handles this by saying there are two "levels" of the rules:

- The base AArch64 AAPCS. Which we use for bare metal right now, and is the basis for all the platforms.
- Specific choices platforms can make on top of that, we have taught clang about these specific cases.

I don't see that breaking from the ABI structure here helps any. You can already do `-target aarch64-whatever-eabi -ffixed-x18` and get what you need.

You can teach clang about your platform too, if you really want to only use 1 option. OpenHarmony is the most recent example.

> I'm not legitimate as a reviewer here, but as a user I'll voice a big +1 for this. It is common to be using target triples with unknown OS, and without this patch, doing so results in very hard to debug issues in code that uses x18.

Actual users are absolutely welcome to chime in :) Far too often that voice is missing.

`-ffixed-x18` really is your solution here if you want the bare metal ABI plus that one change. I do agree that it's annoying to have to find that out many hours into debugging. Perhaps we could better document that these options exist. Do you remember where you looked and what you read when you first chose your `-target` settings?

For instance, if one of those places would document what clang does when the platform is unknown that could help. "if the platform is not recognised, you will likely get the default/bare metal ABI choices for...some platforms will have extra options to control these choices such as....".

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D145131/new/

https://reviews.llvm.org/D145131