[aarch64] XOR the frame pointer with the stack cookie when protecting the stack #161114

PanTao2 · 2025-09-29T02:29:47Z

This strengthens the guard and matches MSVC.

Fixes #156573 .

… the stack

llvmbot · 2025-09-29T02:30:15Z

@llvm/pr-subscribers-llvm-globalisel
@llvm/pr-subscribers-llvm-selectiondag
@llvm/pr-subscribers-backend-x86

@llvm/pr-subscribers-backend-aarch64

Author: Pan Tao (PanTao2)

Changes

Full diff: https://github.com/llvm/llvm-project/pull/161114.diff

3 Files Affected:

(modified) llvm/lib/Target/AArch64/AArch64ISelLowering.cpp (+11-1)
(modified) llvm/lib/Target/AArch64/AArch64ISelLowering.h (+3)
(modified) llvm/lib/Target/AArch64/AArch64SelectionDAGInfo.cpp (+1-1)

diff --git a/llvm/lib/Target/AArch64/AArch64ISelLowering.cpp b/llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
index a4c1e265f0e63..fffc060bbe7cd 100644
--- a/llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
+++ b/llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
@@ -28818,7 +28818,17 @@ void AArch64TargetLowering::ReplaceNodeResults(
 bool AArch64TargetLowering::useLoadStackGuardNode(const Module &M) const {
   if (Subtarget->isTargetAndroid() || Subtarget->isTargetFuchsia())
     return TargetLowering::useLoadStackGuardNode(M);
-  return true;
+  return false;
+}
+
+bool AArch64TargetLowering::useStackGuardXorFP() const { return true; }
+
+SDValue AArch64TargetLowering::emitStackGuardXorFP(SelectionDAG &DAG,
+                                                   SDValue Val,
+                                                   const SDLoc &DL) const {
+  return DAG.getNode(
+      ISD::XOR, DL, Val.getValueType(), Val,
+      DAG.getRegister(getStackPointerRegisterToSaveRestore(), MVT::i64));
 }
 
 unsigned AArch64TargetLowering::combineRepeatedFPDivisors() const {
diff --git a/llvm/lib/Target/AArch64/AArch64ISelLowering.h b/llvm/lib/Target/AArch64/AArch64ISelLowering.h
index d8072d15853ee..8073b0677a11b 100644
--- a/llvm/lib/Target/AArch64/AArch64ISelLowering.h
+++ b/llvm/lib/Target/AArch64/AArch64ISelLowering.h
@@ -349,6 +349,9 @@ class AArch64TargetLowering : public TargetLowering {
   shouldExpandAtomicCmpXchgInIR(AtomicCmpXchgInst *AI) const override;
 
   bool useLoadStackGuardNode(const Module &M) const override;
+  bool useStackGuardXorFP() const override;
+  SDValue emitStackGuardXorFP(SelectionDAG &DAG, SDValue Val,
+                              const SDLoc &DL) const override;
   TargetLoweringBase::LegalizeTypeAction
   getPreferredVectorAction(MVT VT) const override;
 
diff --git a/llvm/lib/Target/AArch64/AArch64SelectionDAGInfo.cpp b/llvm/lib/Target/AArch64/AArch64SelectionDAGInfo.cpp
index d3b1aa621b61a..163de52386221 100644
--- a/llvm/lib/Target/AArch64/AArch64SelectionDAGInfo.cpp
+++ b/llvm/lib/Target/AArch64/AArch64SelectionDAGInfo.cpp
@@ -32,7 +32,7 @@ AArch64SelectionDAGInfo::AArch64SelectionDAGInfo()
 
 void AArch64SelectionDAGInfo::verifyTargetNode(const SelectionDAG &DAG,
                                                const SDNode *N) const {
-  SelectionDAGGenTargetInfo::verifyTargetNode(DAG, N);
+  //  SelectionDAGGenTargetInfo::verifyTargetNode(DAG, N);
 
 #ifndef NDEBUG
   // Some additional checks not yet implemented by verifyTargetNode.

PanTao2 · 2025-10-10T07:22:15Z

@efriedma-quic Could you please review this PR? Is AArch64SelectionDAGInfo::verifyTargetNode() necessary? Only RISCV and AArch64 have implemented this function.

efriedma-quic · 2025-10-10T20:01:14Z

llvm/lib/Target/AArch64/AArch64SelectionDAGInfo.cpp

 void AArch64SelectionDAGInfo::verifyTargetNode(const SelectionDAG &DAG,
                                               const SDNode *N) const {
-  SelectionDAGGenTargetInfo::verifyTargetNode(DAG, N);
+  //  SelectionDAGGenTargetInfo::verifyTargetNode(DAG, N);


Not sure why you're commenting this out?

verifyTargetNode is there to allow targets to implement additional verification for target-specific nodes, to try to catch mistakes early. It isn't strictly necessary to implement it for new nodes, but it's nice to have.

Thank you for your review and explanation!
There is fatal error:

LLVM ERROR: invalid node: operand #0 has invalid type; expected ch, got i64 t18: ch = AArch64ISD::BRCOND t3, BasicBlock:ch<entry 0x59e981fa35b0>, Constant:i32<1>, t16:1 t3: i64,ch = load<(volatile load (s64) from %stack.0.StackGuardSlot)> t0, FrameIndex:i64<0>, undef:i64 t16: i64,i32 = AArch64ISD::SUBS t8, t6

This fatal error is triggered by the following stack:
llvm::report_fatal_error
checkOperandType
llvm::SDNodeInfo::verifyNode "if (HasChain) checkOperandType(DAG, N, 0, MVT::Other);"
llvm::SelectionDAGGenTargetInfo::verifyTargetNode
llvm::AArch64SelectionDAGInfo::verifyTargetNode

What do you suggest in this situation?

That's an actual issue with the structure of the DAG: a node which is supposed to have a chain as the first operand has an operand that isn't a chain. I suspect there's some code that's supposed to return the chain of the load, but is accidentally returning the value of the load instead. (An SDValue is a struct with two members: an SDNode*, and an integer for which result of the SDNode is being referenced.)

This might not be relevant if you switch away from modifying useLoadStackGuardNode.

Yes, this is not relevant after removing the modification of useLoadStackGuardNode.

efriedma-quic · 2025-10-10T20:01:51Z

llvm/test/CodeGen/AArch64/stack-protector-target.ll

-; WINDOWS-AARCH64: adrp x8, __security_cookie
-; WINDOWS-AARCH64: ldr x8, [x8, :lo12:__security_cookie]
+; WINDOWS-AARCH64: adrp x19, __security_cookie
+; WINDOWS-AARCH64: ldr x8, [x19, :lo12:__security_cookie]


It's probably worth making the test check for the "eor" instruction.

I added test check for the "eor" instruction.

efriedma-quic · 2025-10-10T20:07:25Z

llvm/lib/Target/AArch64/AArch64ISelLowering.cpp

@@ -28965,7 +28965,25 @@ void AArch64TargetLowering::ReplaceNodeResults(
 bool AArch64TargetLowering::useLoadStackGuardNode(const Module &M) const {


I'd prefer not to disable useLoadStackGuardNode; it provides additional protection because it prevents later optimizations from incorrectly hoisting the address computations.

You can add the EOR instruction in AArch64InstrInfo::expandPostRAPseudo.

I added the EOR instruction in AArch64InstrInfo::expandPostRAPseudo. Could you please further review it?

efriedma-quic · 2025-10-16T03:56:40Z

llvm/lib/Target/AArch64/AArch64InstrInfo.cpp

+    if (Subtarget.getTargetTriple().isOSMSVCRT() &&
+        !Subtarget.getTargetLowering()
+             ->getTargetMachine()
+             .Options.EnableGlobalISel) {


Do we need the EnableGlobalISel check here?

Probably needs a comment explaining why we're doing this specifically for for MSVCRT targets (to match MSVC).

Can we move this outside the if statement, so it doesn't depend on the code model? We should usually be using small code model for Windows targets, due to the inherent limits of PE-COFF, but some unusual configs like JITs can use other code models.

Yes. Without the EnableGlobalISel check here, the test https://github.com/llvm/llvm-project/blob/main/llvm/test/CodeGen/AArch64/GlobalISel/irtranslator-stack-protector-windows.ll#L2 crash.
I added a simple comment.
Yes. I have moved this outside the if statement.
The eor instruction in the failure BB can not be added in AArch64InstrInfo::expandPostRAPseudo. Therefor, I have modified the existing interface emitStackGuardXorFP to add the eor instruction.
Could you please further review it?

efriedma-quic · 2025-10-20T22:11:34Z

llvm/lib/Target/AArch64/AArch64InstrInfo.cpp

+      !Subtarget.getTargetLowering()
+           ->getTargetMachine()
+           .Options.EnableGlobalISel) {
+    BuildMI(MBB, MI, DL, get(AArch64::EORWrr), Reg)


Suggested change

BuildMI(MBB, MI, DL, get(AArch64::EORWrr), Reg)

BuildMI(MBB, MI, DL, get(AArch64::EORXrr), Reg)

llvm/lib/Target/AArch64/AArch64InstrInfo.cpp

omjavaid · 2025-10-21T12:15:56Z

Hi @PanTao2 thanks for writing this patch. I have general comment first as I think we need some further consideration before going ahead with this change.
On Windows MSVC does this a bit differently on AArch64 vs x64. MSVC uses push pop helpers for /GS checks on AArch64 while on x64 it just inlines the checks and calls security_check_cookie at the end.
Also note MSVC on AArch64 mixes the cookie using sub (sp - cookie) but x64 uses xor (cookie ^ rsp) both do the same job but with diff tradeoffs. XOR is smaller and reversible and sub fits better with overall Arm's stack arithmetic. So if the goal here is to exactly mimic MSVC behavior maybe worth thinking which one is closer or better for LLVM side.... maybe just match the semantics not the exact instr choice what do you think?

PanTao2 · 2025-10-22T07:45:53Z

Hi @omjavaid thanks for your comment. I think you prefer 'only matching semantics'. I think this is great.
My understanding of the difference between aarch64 and x86_64 on Windows MSVC, please correct me if there are any errors.

MSVC uses push pop helpers (calls _security{push|pop}_cookie) on aarch64, while it inlines the checks on x86_64.
MSVC mixes the cookie using sub (sp - cookie) on aarch64, while it mixes the cookie using xor (cookie ^ rsp) on x86_64.

Regarding 1, based on recent optimizations (PR #95904 and PR #136290), I think you prefer inline checks on aarch64. I think it's great.
Regarding 2, thanks for your reminding, I think this is great that using sub (sp - cookie) for fitting better with overall Arm’s stack arithmetic.
What do you think of changing the implementation of this PR to inline sub (sp - cookie)?

PanTao2 · 2025-10-29T09:00:52Z

Hi @omjavaid ping.

omjavaid · 2025-10-29T19:54:25Z

What do you think of changing the implementation of this PR to inline sub (sp - cookie)?

Yes, I think I tend to prefer inlining with sub (sp - cookie)

omjavaid · 2025-10-29T19:58:04Z

My understanding of the difference between aarch64 and x86_64 on Windows MSVC, please correct me if there are any errors.

MSVC uses push pop helpers (calls _security{push|pop}_cookie) on aarch64, while it inlines the checks on x86_64.

MSVC mixes the cookie using sub (sp - cookie) on aarch64, while it mixes the cookie using xor (cookie ^ rsp) on x86_64.

Yes. This is correct. Lets mix the cookie using sub instruction on AArch64 while keep the existing inlining logic intact.

…e from xor to mix

PanTao2 · 2025-11-03T07:09:46Z

Hi @omjavaid I changed the mixed instruction from xor to sub, could you please review the new implementation?

PanTao2 · 2025-11-10T01:25:27Z

Hi @omjavaid ping, thanks.

PanTao2 · 2025-11-13T01:30:14Z

Hi @efriedma-quic, @omjavaid may be on vacation, could you please help to continue to review this PR?

efriedma-quic · 2025-11-13T22:31:26Z

llvm/test/CodeGen/AArch64/stack-protector-target.ll

-; WINDOWS-AARCH64: ldr x0, [sp, #8]
+; WINDOWS-AARCH64: ldr x8, [sp, #8]
+; WINDOWS-AARCH64: mov x9, sp
+; WINDOWS-AARCH64: add x0, x8, x9


Can you commute the operands of the add? add x0, x8, sp is not a legal instruction, but add x0, sp, x8 is legal.

Thank you for correcting.

efriedma-quic · 2025-11-13T22:33:01Z

llvm/test/CodeGen/AArch64/mingw-refptr.ll

 ; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py UTC_ARGS: --version 5
 ; RUN: llc < %s -mtriple=aarch64-w64-mingw32 | FileCheck %s --check-prefixes=CHECK,CHECK-SD
-; RUN: llc < %s -mtriple=aarch64-w64-mingw32 -global-isel | FileCheck %s --check-prefixes=CHECK,CHECK-GI
+; RUN: llc < %s -mtriple=aarch64-w64-mingw32 -global-isel | FileCheck %s --check-prefixes=CHECK-GI


Please regenerate with update_llc_test_checks.py ; don't edit check lines of autogenerated tests by hand.

Thanks, I regenerate this file with update_llc_test_checks.py.

Is update_llc_test_checks.py not happy if you write --check-prefixes=CHECK,CHECK-GI. If that doesn't work, this is fine, I guess.

Sorry for making unnecessary changes. I changed it back to --check-prefixes=CHECK,CHECK-GI and regenerated this file.

…pdate_llc_test_checks.py

efriedma-quic · 2025-11-14T21:25:01Z

llvm/lib/Target/AArch64/AArch64InstrInfo.cpp

+           ->getTargetMachine()
+           .Options.EnableGlobalISel) {
+    BuildMI(MBB, MI, DL, get(AArch64::SUBXrr), Reg)
+        .addReg(AArch64::SP)


Does this actually produce the correct instruction? I'm not sure SP is in the right register class; I suspect you end up subtracting from zero. The wouldn't show up in assembly output, but it would show up in disassembly. (SUBXrx64 can refer to SP this way, though.)

Any reply here?

I changed SUBXrr to SUBXrx64. Could you please check it?

efriedma-quic · 2025-11-14T21:28:16Z

llvm/test/CodeGen/AArch64/stack-protector-target.ll

-; WINDOWS-ARM64EC: ldr x0, [sp, #8]
+; WINDOWS-ARM64EC: ldr x8, [sp, #8]
+; WINDOWS-ARM64EC: mov x9, sp
+; WINDOWS-ARM64EC: add x0, x9, x8


Oh, hmm, this still doesn't actually remove the extra instruction because that would require using a different encoding (ADDXrs vs. ADDXrx64). Shouldn't be too hard to fix; see d337c1f .

github-actions · 2025-11-18T09:13:32Z

🐧 Linux x64 Test Results

186635 tests passed
4888 tests skipped

… the stack

…e from xor to mix

…pdate_llc_test_checks.py

efriedma-quic · 2025-11-18T19:04:46Z

llvm/lib/Target/AArch64/AArch64ISelLowering.cpp

+  if (FailureBB) {
+    return DAG.getNode(
+        ISD::ADD, DL, Val.getValueType(),
+        DAG.getRegister(getStackPointerRegisterToSaveRestore(), MVT::i64), Val);


Please don't use the result of getRegister as an operand to a target-independent ISD::ADD. Register operands aren't values; they are intended only for use with specific operations which are expecting them.

It might appear to work here, sort-of, but other parts of the DAG aren't expecting it, and it will lead to weird results in general. And I'm not sure it actually is working correctly here... what's the actual encoding you're getting?

When running llvm/test/CodeGen/AArch64/stack-protector-target.ll, the SDValue returned by DAG.getRegister (getRegister(getStackPointerRegisterToSaveRestore(), MVT:: i64) is "t4: i64 = Register $physreg8".
DAG.getRegister wraps Register as SDValue, while DAG.getCopyFromReg (used in previous version) uses DAG.getRegister and adds a move (copy) instruction.

I moved the target-independent ISD::ADD to the target-independent class SelectionDAG. Could you please further review it?

efriedma-quic · 2025-11-25T22:29:49Z

llvm/test/CodeGen/AArch64/mingw-refptr.ll

 ; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py UTC_ARGS: --version 5
 ; RUN: llc < %s -mtriple=aarch64-w64-mingw32 | FileCheck %s --check-prefixes=CHECK,CHECK-SD
-; RUN: llc < %s -mtriple=aarch64-w64-mingw32 -global-isel | FileCheck %s --check-prefixes=CHECK,CHECK-GI
+; RUN: llc < %s -mtriple=aarch64-w64-mingw32 -global-isel | FileCheck %s --check-prefixes=CHECK-GI


Is update_llc_test_checks.py not happy if you write --check-prefixes=CHECK,CHECK-GI. If that doesn't work, this is fine, I guess.

efriedma-quic · 2025-11-25T22:30:16Z

llvm/lib/Target/AArch64/AArch64InstrInfo.cpp

+           ->getTargetMachine()
+           .Options.EnableGlobalISel) {
+    BuildMI(MBB, MI, DL, get(AArch64::SUBXrr), Reg)
+        .addReg(AArch64::SP)


Any reply here?

efriedma-quic · 2025-11-25T22:33:34Z

llvm/include/llvm/CodeGen/SelectionDAG.h

  }

+  SDValue getAddToReg(const SDLoc &dl, Register Reg, EVT VT, SDValue Delta) {
+    return getNode(ISD::ADD, dl, VT, getRegister(Reg, VT), Delta);


Moving the code around doesn't solve the fundamental issue that you actually need to CopyFromReg for correctness.

Please take another look at d337c1f , specifically how it added the copyFromSP pattern.

I deleted the copyFromSp instruction by referring to d337c1f. Could you please check it?

…efptr.ll

efriedma-quic · 2025-11-26T21:09:49Z

llvm/lib/Target/AArch64/AArch64InstrInfo.cpp

          .addMemOperand(*MI.memoperands_begin());
    }
  }
+  // To match MSVC


Maybe extend this comment a little to explain what exactly we're matching.

Could you please review the added comment?

efriedma-quic · 2025-11-26T21:14:06Z

llvm/lib/Target/AArch64/AArch64ISelDAGToDAG.cpp

+bool AArch64DAGToDAGISel::SelectAddUXTXRegister(SDValue N, SDValue &Reg,
+                                                SDValue &Shift) {
+  if (N.getOpcode() != ISD::LOAD)
+    return false;


Is there any particular reason to check for a LOAD? The pattern seems like it should still work for non-LOAD operands.

If the LOAD is not checked, there will be many unexpected changes. E.g., the following code

stur x10, [x29, #-200] // 8-byte Folded Spill mov x15, sp subs x10, x15, #16

will be changed to

stur x10, [x29, #-200] mov x15, sp add x10, x15, x8, uxtx

PanTao2

I'm very sorry, I was informed that some of my comments were not sent out.

PanTao2 · 2025-10-16T07:03:41Z

llvm/lib/Target/AArch64/AArch64InstrInfo.cpp

+    if (Subtarget.getTargetTriple().isOSMSVCRT() &&
+        !Subtarget.getTargetLowering()
+             ->getTargetMachine()
+             .Options.EnableGlobalISel) {


Yes. Without the EnableGlobalISel check here, the test https://github.com/llvm/llvm-project/blob/main/llvm/test/CodeGen/AArch64/GlobalISel/irtranslator-stack-protector-windows.ll#L2 crash.
I added a simple comment.
Yes. I have moved this outside the if statement.
The eor instruction in the failure BB can not be added in AArch64InstrInfo::expandPostRAPseudo. Therefor, I have modified the existing interface emitStackGuardXorFP to add the eor instruction.
Could you please further review it?

PanTao2 · 2025-10-21T02:01:43Z

llvm/lib/Target/AArch64/AArch64InstrInfo.cpp

+      !Subtarget.getTargetLowering()
+           ->getTargetMachine()
+           .Options.EnableGlobalISel) {
+    BuildMI(MBB, MI, DL, get(AArch64::EORWrr), Reg)


llvm/lib/Target/AArch64/AArch64InstrInfo.cpp

PanTao2 · 2025-11-14T07:36:27Z

llvm/test/CodeGen/AArch64/stack-protector-target.ll

-; WINDOWS-AARCH64: ldr x0, [sp, #8]
+; WINDOWS-AARCH64: ldr x8, [sp, #8]
+; WINDOWS-AARCH64: mov x9, sp
+; WINDOWS-AARCH64: add x0, x8, x9


Thank you for correcting.

PanTao2 · 2025-11-14T07:36:36Z

llvm/test/CodeGen/AArch64/mingw-refptr.ll

 ; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py UTC_ARGS: --version 5
 ; RUN: llc < %s -mtriple=aarch64-w64-mingw32 | FileCheck %s --check-prefixes=CHECK,CHECK-SD
-; RUN: llc < %s -mtriple=aarch64-w64-mingw32 -global-isel | FileCheck %s --check-prefixes=CHECK,CHECK-GI
+; RUN: llc < %s -mtriple=aarch64-w64-mingw32 -global-isel | FileCheck %s --check-prefixes=CHECK-GI


Thanks, I regenerate this file with update_llc_test_checks.py.

PanTao2 · 2025-11-19T02:25:12Z

llvm/lib/Target/AArch64/AArch64ISelLowering.cpp

+  if (FailureBB) {
+    return DAG.getNode(
+        ISD::ADD, DL, Val.getValueType(),
+        DAG.getRegister(getStackPointerRegisterToSaveRestore(), MVT::i64), Val);


When running llvm/test/CodeGen/AArch64/stack-protector-target.ll, the SDValue returned by DAG.getRegister (getRegister(getStackPointerRegisterToSaveRestore(), MVT:: i64) is "t4: i64 = Register $physreg8".
DAG.getRegister wraps Register as SDValue, while DAG.getCopyFromReg (used in previous version) uses DAG.getRegister and adds a move (copy) instruction.

PanTao2 · 2025-11-25T05:57:12Z

llvm/lib/Target/AArch64/AArch64ISelLowering.cpp

+  if (FailureBB) {
+    return DAG.getNode(
+        ISD::ADD, DL, Val.getValueType(),
+        DAG.getRegister(getStackPointerRegisterToSaveRestore(), MVT::i64), Val);


I moved the target-independent ISD::ADD to the target-independent class SelectionDAG. Could you please further review it?

PanTao2 · 2025-11-26T09:54:32Z

llvm/test/CodeGen/AArch64/mingw-refptr.ll

 ; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py UTC_ARGS: --version 5
 ; RUN: llc < %s -mtriple=aarch64-w64-mingw32 | FileCheck %s --check-prefixes=CHECK,CHECK-SD
-; RUN: llc < %s -mtriple=aarch64-w64-mingw32 -global-isel | FileCheck %s --check-prefixes=CHECK,CHECK-GI
+; RUN: llc < %s -mtriple=aarch64-w64-mingw32 -global-isel | FileCheck %s --check-prefixes=CHECK-GI


Sorry for making unnecessary changes. I changed it back to --check-prefixes=CHECK,CHECK-GI and regenerated this file.

PanTao2 · 2025-11-26T09:55:16Z

llvm/include/llvm/CodeGen/SelectionDAG.h

  }

+  SDValue getAddToReg(const SDLoc &dl, Register Reg, EVT VT, SDValue Delta) {
+    return getNode(ISD::ADD, dl, VT, getRegister(Reg, VT), Delta);


I deleted the copyFromSp instruction by referring to d337c1f. Could you please check it?

PanTao2 · 2025-11-26T09:56:50Z

llvm/lib/Target/AArch64/AArch64InstrInfo.cpp

+           ->getTargetMachine()
+           .Options.EnableGlobalISel) {
+    BuildMI(MBB, MI, DL, get(AArch64::SUBXrr), Reg)
+        .addReg(AArch64::SP)


I changed SUBXrr to SUBXrx64. Could you please check it?

[aarch64] XOR the frame pointer with the stack cookie when protecting…

9c6d4c7

… the stack

llvmbot added the backend:AArch64 label Sep 29, 2025

PanTao2 force-pushed the my_change branch from d507f66 to 309524a Compare October 10, 2025 03:22

efriedma-quic reviewed Oct 10, 2025

View reviewed changes

efriedma-quic requested a review from omjavaid October 16, 2025 03:23

efriedma-quic reviewed Oct 16, 2025

View reviewed changes

llvmbot added backend:X86 llvm:SelectionDAG SelectionDAGISel as well labels Oct 17, 2025

efriedma-quic reviewed Oct 20, 2025

View reviewed changes

PanTao2 added 7 commits October 29, 2025 14:25

Merge branch 'main' of https://github.com/llvm/llvm-project

da07652

Change DAG.getRegister to DAG.getCopyFromReg

00dddda

Fix failed tests

5c230ae

Add the EOR instruction in AArch64InstrInfo::expandPostRAPseudo

12ded1e

Add the eor instruction to any code model

23fbbbb

Add the eor instruction in the failure BB

c61707a

Remove the isTargetMachO() check and change EORWrr to EORXrr

2b02cb2

PanTao2 force-pushed the my_change branch from f273fa9 to 2b02cb2 Compare October 29, 2025 08:08

Change the mixed instruction from xor to sub and change interface nam…

823bd2f

…e from xor to mix

llvmbot added llvm:codegen llvm:globalisel labels Nov 3, 2025

efriedma-quic reviewed Nov 13, 2025

View reviewed changes

Commute the operands of the add and regenerate mingw-refptr.ll with u…

9f95a65

…pdate_llc_test_checks.py

efriedma-quic reviewed Nov 14, 2025

View reviewed changes

Remove the extra instruction that copy from sp

6606db9

PanTao2 added 11 commits November 18, 2025 21:26

[aarch64] XOR the frame pointer with the stack cookie when protecting…

c27d13d

… the stack

Change DAG.getRegister to DAG.getCopyFromReg

6536678

Fix failed tests

4493e86

Add the EOR instruction in AArch64InstrInfo::expandPostRAPseudo

c5b61ae

Add the eor instruction to any code model

2763964

Add the eor instruction in the failure BB

414995a

Remove the isTargetMachO() check and change EORWrr to EORXrr

65acb8c

Change the mixed instruction from xor to sub and change interface nam…

df09547

…e from xor to mix

Commute the operands of the add and regenerate mingw-refptr.ll with u…

2e737b9

…pdate_llc_test_checks.py

Remove the extra instruction that copy from sp

b9ae3ff

rebase

bb1bf30

PanTao2 force-pushed the my_change branch from 6606db9 to bb1bf30 Compare November 18, 2025 15:18

efriedma-quic reviewed Nov 18, 2025

View reviewed changes

PanTao2 requested a review from efriedma-quic November 21, 2025 04:58

Add function getAddToReg to the class SelectionDAG

33de52f

efriedma-quic reviewed Nov 25, 2025

View reviewed changes

Add add_uxtx complex pattern, SUBXrr -> SUBXrx64, re-generate mingw-r…

b41ab42

…efptr.ll

efriedma-quic reviewed Nov 26, 2025

View reviewed changes

Fix conflict

36782f4

PanTao2 commented Nov 27, 2025

View reviewed changes

Add more comment

5076be4

PanTao2 force-pushed the my_change branch from 511a312 to 5076be4 Compare November 27, 2025 05:48

		@@ -28965,7 +28965,25 @@ void AArch64TargetLowering::ReplaceNodeResults(
		bool AArch64TargetLowering::useLoadStackGuardNode(const Module &M) const {

	BuildMI(MBB, MI, DL, get(AArch64::EORWrr), Reg)
	BuildMI(MBB, MI, DL, get(AArch64::EORXrr), Reg)

[aarch64] XOR the frame pointer with the stack cookie when protecting the stack #161114

Are you sure you want to change the base?

[aarch64] XOR the frame pointer with the stack cookie when protecting the stack #161114

Uh oh!

Conversation

PanTao2 commented Sep 29, 2025 • edited by efriedma-quic Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

llvmbot commented Sep 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

PanTao2 commented Oct 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

omjavaid commented Oct 21, 2025

Uh oh!

PanTao2 commented Oct 22, 2025

Uh oh!

PanTao2 commented Oct 29, 2025

Uh oh!

omjavaid commented Oct 29, 2025

Uh oh!

omjavaid commented Oct 29, 2025

Uh oh!

PanTao2 commented Nov 3, 2025

Uh oh!

PanTao2 commented Nov 10, 2025

Uh oh!

PanTao2 commented Nov 13, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

github-actions bot commented Nov 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🐧 Linux x64 Test Results

PanTao2 commented Sep 29, 2025 •

edited by efriedma-quic

Loading

llvmbot commented Sep 29, 2025 •

edited

Loading

PanTao2 commented Oct 10, 2025 •

edited

Loading

github-actions bot commented Nov 18, 2025 •

edited

Loading