Skip to content

[Mem2Reg] Don't use single store optimization for potentially poison value #97711

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jul 4, 2024

Conversation

nikic
Copy link
Contributor

@nikic nikic commented Jul 4, 2024

If there is a single store, then loads must either load the stored value or uninitialized memory (undef). If the stored value may be poison, then replacing an uninitialized memory load with it would be incorrect. Fall back to the generic code in that case.

This PR only fixes the case where there is a literal poison store -- the case where the value is non-trivially poison will still get miscompiled by phi simplification later, see #96631.

Fixes #97702.

…value

If there is a single store, then loads must either load the stored
value or uninitialized memory (undef). If the stored value may be
poison, then replacing an uninitialized memory load with it would
be incorrect. Fall back to the generic code in that case.

This PR only fixes the case where there is a literal poison store
-- the case where the value is non-trivially poison will be
miscompiled by phi simplification later, see llvm#96631.

Fixes llvm#97702.
@llvmbot
Copy link
Member

llvmbot commented Jul 4, 2024

@llvm/pr-subscribers-llvm-transforms

Author: Nikita Popov (nikic)

Changes

If there is a single store, then loads must either load the stored value or uninitialized memory (undef). If the stored value may be poison, then replacing an uninitialized memory load with it would be incorrect. Fall back to the generic code in that case.

This PR only fixes the case where there is a literal poison store -- the case where the value is non-trivially poison will still get miscompiled by phi simplification later, see #96631.

Fixes #97702.


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

2 Files Affected:

  • (modified) llvm/lib/Transforms/Utils/PromoteMemoryToRegister.cpp (+8-2)
  • (modified) llvm/test/Transforms/Mem2Reg/single-store.ll (+1-2)
diff --git a/llvm/lib/Transforms/Utils/PromoteMemoryToRegister.cpp b/llvm/lib/Transforms/Utils/PromoteMemoryToRegister.cpp
index 6e021a5e2d05a..cd5ab55c2122f 100644
--- a/llvm/lib/Transforms/Utils/PromoteMemoryToRegister.cpp
+++ b/llvm/lib/Transforms/Utils/PromoteMemoryToRegister.cpp
@@ -525,7 +525,14 @@ rewriteSingleStoreAlloca(AllocaInst *AI, AllocaInfo &Info, LargeBlockInfo &LBI,
                          SmallSet<DbgAssignIntrinsic *, 8> *DbgAssignsToDelete,
                          SmallSet<DbgVariableRecord *, 8> *DVRAssignsToDelete) {
   StoreInst *OnlyStore = Info.OnlyStore;
-  bool StoringGlobalVal = !isa<Instruction>(OnlyStore->getOperand(0));
+  Value *ReplVal = OnlyStore->getOperand(0);
+  // Loads may either load the stored value or uninitialized memory (undef).
+  // If the stored value may be poison, then replacing an uninitialized memory
+  // load with it would be incorrect.
+  if (!isGuaranteedNotToBePoison(ReplVal))
+    return false;
+
+  bool StoringGlobalVal = !isa<Instruction>(ReplVal);
   BasicBlock *StoreBB = OnlyStore->getParent();
   int StoreIndex = -1;
 
@@ -565,7 +572,6 @@ rewriteSingleStoreAlloca(AllocaInst *AI, AllocaInfo &Info, LargeBlockInfo &LBI,
     }
 
     // Otherwise, we *can* safely rewrite this load.
-    Value *ReplVal = OnlyStore->getOperand(0);
     // If the replacement value is the load, this must occur in unreachable
     // code.
     if (ReplVal == LI)
diff --git a/llvm/test/Transforms/Mem2Reg/single-store.ll b/llvm/test/Transforms/Mem2Reg/single-store.ll
index b82e26158a361..f864227c49145 100644
--- a/llvm/test/Transforms/Mem2Reg/single-store.ll
+++ b/llvm/test/Transforms/Mem2Reg/single-store.ll
@@ -1,7 +1,6 @@
 ; NOTE: Assertions have been autogenerated by utils/update_test_checks.py UTC_ARGS: --version 5
 ; RUN: opt -S -passes=mem2reg < %s | FileCheck %s
 
-; FIXME: This is a miscompile.
 define i8 @single_store_literal_poison(i1 %cond) {
 ; CHECK-LABEL: define i8 @single_store_literal_poison(
 ; CHECK-SAME: i1 [[COND:%.*]]) {
@@ -9,7 +8,7 @@ define i8 @single_store_literal_poison(i1 %cond) {
 ; CHECK:       [[IF]]:
 ; CHECK-NEXT:    br label %[[EXIT]]
 ; CHECK:       [[EXIT]]:
-; CHECK-NEXT:    ret i8 poison
+; CHECK-NEXT:    ret i8 undef
 ;
   %a = alloca i8, align 1
   br i1 %cond, label %if, label %exit

Copy link
Member

@dianqk dianqk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

@nikic nikic merged commit f58930f into llvm:main Jul 4, 2024
7 of 8 checks passed
@nikic nikic deleted the mem2reg-fix branch July 4, 2024 12:41
dianqk pushed a commit to dianqk/llvm-project that referenced this pull request Jul 5, 2024
…value (llvm#97711)

If there is a single store, then loads must either load the stored value
or uninitialized memory (undef). If the stored value may be poison, then
replacing an uninitialized memory load with it would be incorrect. Fall
back to the generic code in that case.

This PR only fixes the case where there is a literal poison store -- the
case where the value is non-trivially poison will still get miscompiled
by phi simplification later, see llvm#96631.

Fixes llvm#97702.

(cherry picked from commit f58930f)
nikic added a commit that referenced this pull request Jul 5, 2024
In #97711 the single-store optimization was disabled for the case
where the value is potentially poison, as this may produce incorrect
results for loads of uninitialized memory.

However, this resulted in compile-time regressions. Address these
by still allowing the single-store optimization to occur in cases
where the store dominates the load, as we know that such a load
will always read initialized memory.
dianqk pushed a commit to dianqk/llvm-project that referenced this pull request Jul 5, 2024
In llvm#97711 the single-store optimization was disabled for the case
where the value is potentially poison, as this may produce incorrect
results for loads of uninitialized memory.

However, this resulted in compile-time regressions. Address these
by still allowing the single-store optimization to occur in cases
where the store dominates the load, as we know that such a load
will always read initialized memory.

(cherry picked from commit daaea12)
nikic added a commit to rust-lang/llvm-project that referenced this pull request Jul 5, 2024
…value (llvm#97711)

If there is a single store, then loads must either load the stored value
or uninitialized memory (undef). If the stored value may be poison, then
replacing an uninitialized memory load with it would be incorrect. Fall
back to the generic code in that case.

This PR only fixes the case where there is a literal poison store -- the
case where the value is non-trivially poison will still get miscompiled
by phi simplification later, see llvm#96631.

Fixes llvm#97702.

(cherry picked from commit f58930f)
nikic added a commit to rust-lang/llvm-project that referenced this pull request Jul 5, 2024
In llvm#97711 the single-store optimization was disabled for the case
where the value is potentially poison, as this may produce incorrect
results for loads of uninitialized memory.

However, this resulted in compile-time regressions. Address these
by still allowing the single-store optimization to occur in cases
where the store dominates the load, as we know that such a load
will always read initialized memory.

(cherry picked from commit daaea12)
kbluck pushed a commit to kbluck/llvm-project that referenced this pull request Jul 6, 2024
…value (llvm#97711)

If there is a single store, then loads must either load the stored value
or uninitialized memory (undef). If the stored value may be poison, then
replacing an uninitialized memory load with it would be incorrect. Fall
back to the generic code in that case.

This PR only fixes the case where there is a literal poison store -- the
case where the value is non-trivially poison will still get miscompiled
by phi simplification later, see llvm#96631.

Fixes llvm#97702.
kbluck pushed a commit to kbluck/llvm-project that referenced this pull request Jul 6, 2024
In llvm#97711 the single-store optimization was disabled for the case
where the value is potentially poison, as this may produce incorrect
results for loads of uninitialized memory.

However, this resulted in compile-time regressions. Address these
by still allowing the single-store optimization to occur in cases
where the store dominates the load, as we know that such a load
will always read initialized memory.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Mem2Reg] Incorrect poison propagation
3 participants