[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