[llvm] [AArch64][PAC] Lower jump-tables using hardened pseudo. (PR #97666)
Ahmed Bougacha via llvm-commits
llvm-commits at lists.llvm.org
Tue Jul 16 18:00:38 PDT 2024
================
@@ -3597,10 +3597,22 @@ bool AArch64InstructionSelector::selectBrJT(MachineInstr &I,
unsigned JTI = I.getOperand(1).getIndex();
Register Index = I.getOperand(2).getReg();
+ MF->getInfo<AArch64FunctionInfo>()->setJumpTableEntryInfo(JTI, 4, nullptr);
+ if (MF->getFunction().hasFnAttribute("jump-table-hardening") ||
+ STI.getTargetTriple().isArm64e()) {
+ if (TM.getCodeModel() != CodeModel::Small)
----------------
ahmedbougacha wrote:
Yeah, SDAG/GISel should both have the same support. The situation with the large code model is more complicated.
Currently, the AsmPrinter expansion materializes the jump-table address using `adrp`/`add`. On MachO, that's okay(-ish) for the large code-model as well, but that's not what's done on ELF (per `AArch64TargetLowering::LowerJumpTable`).
I don't see an explicit rationale in the code or history, but I could justify it with ELF always using a different section for the jump-table itself, vs. MachO ~always having it inline with the function. In the latter case, I think we can usually get away without the 4x `movk` large code-model materialization sequence, so we end up with the same desired `adrp`/`add` codegen for large/small code models on MachO, but not ELF.
Of course we can teach the expansion about non-`adrp`/`add` materialization variants, but let's add that separately.
https://github.com/llvm/llvm-project/pull/97666
More information about the llvm-commits
mailing list