[all-commits] [llvm/llvm-project] 329f45: [CodeGen][SafeStack] Successful InlineFunction sho...

[Douglas via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 329f45430835fe803b753ac78fc823b5dfc5df69
      https://github.com/llvm/llvm-project/commit/329f45430835fe803b753ac78fc823b5dfc5df69
  Author: Douglas <Douglas.Gliner at sony.com>
  Date:   2026-09-11 (Fri, 11 Sep 2026)

  Changed paths:
    M llvm/lib/CodeGen/SafeStack.cpp
    A llvm/test/Transforms/SafeStack/X86/pointer-address-domtree.ll

  Log Message:
  -----------
  [CodeGen][SafeStack] Successful InlineFunction should force a recalculation of potentially stale DominatorTree (#222820)

In commit 51a25846c198, Safe Stack began preserving the `DominatorTree`
by the end of the pass' run. Updates to the `DominatorTree` were then
made lazily via inclusion of `DomTreeUpdater` and its use with
`SplitBlockAndInsertIfThen`. Preservation was maintained when updated to
the new pass manager in 3bd517205799. However, there was an overlooked
case where the `DominatorTree` would remain stale by the end of the Safe
Stack pass if the actions under `TryInlinePointerAddress` completed
successfully and modified the caller's CFG.

The conditions for a stale `DominatorTree` to exist are roughly:
1. Safe Stack obtains the Unsafe Stack pointer location as a `CallInst`
(i.e. one way is `-safestack-use-pointer-address`)
2. `__safestack_pointer_address` is defined and inlined successfully.
3. The inlining changes the CFG such that a recalculated `DominatorTree`
would differ.
4. `DominatorTree` remains unchanged since it is preserved and currently
not recalculated.

Here's a simple example that demonstrates the issue:
```
@unsafe_stack_pointer_a = thread_local global ptr null
@unsafe_stack_pointer_b = thread_local global ptr null

declare i32 @get_runtime_mode() nounwind willreturn memory(none)
declare void @escape(ptr)

define ptr @__safestack_pointer_address() alwaysinline {
entry:
  %first = call i32 @get_runtime_mode()
  %use_a = icmp eq i32 %first, 0
  br i1 %use_a, label %a, label %b

a:
  ret ptr @unsafe_stack_pointer_a

b:
  ret ptr @unsafe_stack_pointer_b
}

define i32 @caller() safestack {
entry:
  %unsafe = alloca i32, align 4
  call void @escape(ptr %unsafe)
  %second = call i32 @get_runtime_mode()
  ret i32 %second
}
```

```
> opt -mtriple=x86_64-pc-linux-gnu -safestack-use-pointer-address -passes=require<libcall-lowering-info>,function(safe-stack,verify<domtree>) -disable-output example.ll
DominatorTree is different than a freshly computed one!
	Current:
=============================--------------------------------
Inorder Dominator Tree: DFSNumbers invalid: 0 slow queries.
  [1] %entry {4294967295,4294967295} [0]
Roots: %entry

	Freshly computed tree:
=============================--------------------------------
Inorder Dominator Tree: DFSNumbers invalid: 0 slow queries.
  [1] %entry {4294967295,4294967295} [0]
    [2] %a.i {4294967295,4294967295} [1]
    [2] %__safestack_pointer_address.exit {4294967295,4294967295} [1]
    [2] %b.i {4294967295,4294967295} [1]
Roots: %entry
```

To avoid a stale `DominatorTree` by the end of the Safe Stack pass, I
propose calling `recalculate` on the `DominatorTree` for the function
which will have the call to `__safestack_pointer_address` inlined
assuming the inlining was successful and `DomTreeUpdater` is non-NULL.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications