This is mostly straightforward, with an additional optimization: XPACIuntied allows strips of LR (which we emit in __builtin_return_address) to avoid clobbering LR. (This can be useful, e.g., for a certain kind of wrapper functions that just forward the caller address, for logging and such)
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Target/AArch64/GISel/AArch64InstructionSelector.cpp | ||
---|---|---|
5873 | Can the Key be 2? Is an if-statement easier to comprehend than a ternary operator? |
llvm/lib/Target/AArch64/AArch64ExpandPseudoInsts.cpp | ||
---|---|---|
1227 ↗ | (On Diff #454524) | there is no unit test case for this scenario |
llvm/lib/Target/AArch64/GISel/AArch64InstructionSelector.cpp | ||
---|---|---|
5873 | I guess having an enum for the valid key descriptors for AArch64 would make this and other code working with keys more readable. I'm not sure if that's typically done or where to define that enum? I see these constants 0,1,2,3 are also needed in tablegen files. Not sure if something similar to an enum exists in Tablegen? |
- Extract out XPACIuntied, leaving it for ptrauth-returns.
- Pull in key/opcode helper functions from later patch in the series.
llvm/lib/Target/AArch64/AArch64ExpandPseudoInsts.cpp | ||
---|---|---|
1227 ↗ | (On Diff #454524) | Yeah, XPACIuntied is really intended to be used in @llvm.returnaddress when return address signing (/PAC-RET) is enabled. I pulled it out of this patch into that one, where it actually gets exercised. |
llvm/lib/Target/AArch64/GISel/AArch64InstructionSelector.cpp | ||
5873 | A later patch in the series actually does introduce helper functions in AArch64BaseInfo.h/AArch64InstrInfo.h, so it's a simple matter of using them here! I combined the two in this review, to be committed separately. |
LGTM!
I just added a few minor nitpicks - I'll leave it to you to decide if following those suggestions would result in an improvement or not.
llvm/lib/Target/AArch64/AArch64InstrInfo.h | ||
---|---|---|
514 ↗ | (On Diff #456771) | nitpick, maybe do s/ptrauth auth/pointer authentication/? |
526 ↗ | (On Diff #456771) | nitpick, maybe do s/ptrauth auth/pointer signing/? |
llvm/lib/Target/AArch64/Utils/AArch64BaseInfo.h | ||
798 ↗ | (On Diff #456771) | I guess that if we added "LAST = 3" here, the somewhat cryptic if statement in AArch64InstructionSelector.cpp that says if (Key > 3) return false; could instead say something like if (AArch64PACKey::LAST > 3) return false; It seems the word "LAST" is already used in a few other places in LLVM to indicate the highest defined value in an enum. Maybe doing this change would be a minor improvement in readability/maintainability? |
Can the Key be 2? Is an if-statement easier to comprehend than a ternary operator?