[llvm] [SelectionDAG] Fix dangling SUnit node after unfold during scheduling (PR #202295)

Matt Arsenault via llvm-commits llvm-commits at lists.llvm.org
Sun Sep 13 23:46:08 PDT 2026


================
@@ -0,0 +1,85 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc < %s -mtriple=x86_64-unknown-linux-gnu | FileCheck %s --check-prefix=RRLIST
+; RUN: llc < %s -mtriple=x86_64-unknown-linux-gnu -pre-RA-sched=fast | FileCheck %s --check-prefix=FAST
+
+; Make sure this does not crash with "Node emitted out of order - early".
+; Unfolding a load during scheduling replaces all uses of the folded node,
+; which can CSE-merge and delete a node still referenced by another SUnit.
+; Both the list (ScheduleDAGRRList) and fast (ScheduleDAGFast) schedulers
+; perform this unfold, so exercise both.
+
+ at G.1 = external global i1
+ at G.5 = external global ptr
+
+define void @pr63309(ptr %G.5, i64 %L3) {
+; RRLIST-LABEL: pr63309:
+; RRLIST:       # %bb.0: # %BB
+; RRLIST-NEXT:    movzbl -{{[0-9]+}}(%rsp), %eax
+; RRLIST-NEXT:    andl $1, %eax
+; RRLIST-NEXT:    negq %rax
+; RRLIST-NEXT:    movb $0, -{{[0-9]+}}(%rsp)
+; RRLIST-NEXT:    movzbl (%rax), %eax
+; RRLIST-NEXT:    movq G.1 at GOTPCREL(%rip), %rcx
+; RRLIST-NEXT:    movq 0, %rdx
+; RRLIST-NEXT:    movb $0, (%rcx)
+; RRLIST-NEXT:    movq $0, -{{[0-9]+}}(%rsp)
+; RRLIST-NEXT:    movq G.5 at GOTPCREL(%rip), %rcx
+; RRLIST-NEXT:    movq $0, (%rcx)
+; RRLIST-NEXT:    testq %rsi, %rsi
+; RRLIST-NEXT:    setg 0
+; RRLIST-NEXT:    testq %rdx, %rdx
+; RRLIST-NEXT:    movq $0, (%rdi)
+; RRLIST-NEXT:    movb %al, 0
+; RRLIST-NEXT:    setne (%rdi)
+; RRLIST-NEXT:    testb %al, %al
+; RRLIST-NEXT:    sets 0
+; RRLIST-NEXT:    retq
+;
+; FAST-LABEL: pr63309:
+; FAST:       # %bb.0: # %BB
+; FAST-NEXT:    movq G.1 at GOTPCREL(%rip), %rax
+; FAST-NEXT:    movzbl -{{[0-9]+}}(%rsp), %ecx
+; FAST-NEXT:    andl $1, %ecx
+; FAST-NEXT:    negq %rcx
+; FAST-NEXT:    movb $0, -{{[0-9]+}}(%rsp)
+; FAST-NEXT:    movzbl (%rcx), %ecx
+; FAST-NEXT:    movq 0, %rdx
+; FAST-NEXT:    movb $0, (%rax)
+; FAST-NEXT:    movq G.5 at GOTPCREL(%rip), %rax
+; FAST-NEXT:    movq $0, (%rax)
+; FAST-NEXT:    movq $0, -{{[0-9]+}}(%rsp)
+; FAST-NEXT:    testq %rsi, %rsi
+; FAST-NEXT:    setg 0
+; FAST-NEXT:    testq %rdx, %rdx
+; FAST-NEXT:    movq $0, (%rdi)
+; FAST-NEXT:    movb %cl, 0
+; FAST-NEXT:    setne (%rdi)
+; FAST-NEXT:    testb %cl, %cl
+; FAST-NEXT:    sets 0
+; FAST-NEXT:    retq
+BB:
+  %A31 = alloca i1, i32 0, align 1
+  %A = alloca i1, i32 0, align 1
+  %L2 = load i1, ptr %A, align 1
+  %L = load i1, ptr %A, align 1
+  store i1 poison, ptr null, align 1
----------------
arsenm wrote:

Can you avoid depending on UB in the test 

https://github.com/llvm/llvm-project/pull/202295


More information about the llvm-commits mailing list