================
@@ -1206,11 +1217,24 @@ struct DSEState {
     return OW_None;
   }
 
-  bool isInvisibleToCallerAfterRet(const Value *V) {
+  bool isInvisibleToCallerAfterRet(const Value *V, const Value *Ptr,
+                                   const LocationSize StoreSize) {
     if (isa<AllocaInst>(V))
       return true;
 
     auto I = InvisibleToCallerAfterRet.insert({V, false});
+    if (I.second && InvisibleToCallerAfterRetBounded.contains(V)) {
+      int64_t ValueOffset;
+      const Value *BaseValue =
+          GetPointerBaseWithConstantOffset(Ptr, ValueOffset, DL);
+      assert(BaseValue == V);
+      // This store is only invisible after return if we are in bounds of the
+      // range marked dead.
+      if (ValueOffset + StoreSize.getValue() <=
+              InvisibleToCallerAfterRetBounded[BaseValue] &&
+          ValueOffset >= 0)
+        return true;
+    }
     if (I.second && isInvisibleToCallerOnUnwind(V) && isNoAliasCall(V))
----------------
boomanaiden154 wrote:

We only end up in this case if we inserted into the array (i.e., the pointer is 
not explicitly marked `dead_on_return`) but is marked `dead_on_unwind`. For 
objects marked dead_on_return the underlying object will always be explicitly 
marked, so we will never insert at this point anyways. If they're not marked 
dead_on_return, we get the same behavior.

We also do not want to potentially insert true into `InvisibleToCallerAfterRet` 
because then we would not be looking at bounds information when we should be.

Also realizing now after looking at this we do not want to be inserting into 
`InvisibleToCallerAfterRet` at all before we check for bounded dead_on_return 
annotations because otherwise we might erroneously report false if we have two 
stores at the end of a function to the same underlying object. Fixed + 
regression test added.

https://github.com/llvm/llvm-project/pull/173694
_______________________________________________
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

Reply via email to