[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