[PATCH] D99648: [GVN] Refactor analyzeLoadFromClobberingWrite to simplify code

[Phabricator via llvm-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG62b74f75645f: [GVN][NFC] Refactor analyzeLoadFromClobberingWrite (authored by qixingxue <qixingxue at outlook.com>).

Changed prior to commit:
  https://reviews.llvm.org/D99648?vs=334400&id=334565#toc

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D99648/new/

https://reviews.llvm.org/D99648

Files:
  llvm/lib/Transforms/Utils/VNCoercion.cpp


Index: llvm/lib/Transforms/Utils/VNCoercion.cpp
===================================================================
--- llvm/lib/Transforms/Utils/VNCoercion.cpp
+++ llvm/lib/Transforms/Utils/VNCoercion.cpp
@@ -189,14 +189,6 @@
   if (StoreBase != LoadBase)
     return -1;
 
-  // If the load and store are to the exact same address, they should have been
-  // a must alias.  AA must have gotten confused.
-  // FIXME: Study to see if/when this happens.  One case is forwarding a memset
-  // to a load from the base of the memset.
-
-  // If the load and store don't overlap at all, the store doesn't provide
-  // anything to the load.  In this case, they really don't alias at all, AA
-  // must have gotten confused.
   uint64_t LoadSize = DL.getTypeSizeInBits(LoadTy).getFixedSize();
 
   if ((WriteSizeInBits & 7) | (LoadSize & 7))
@@ -204,15 +196,6 @@
   uint64_t StoreSize = WriteSizeInBits / 8; // Convert to bytes.
   LoadSize /= 8;
 
-  bool isAAFailure = false;
-  if (StoreOffset < LoadOffset)
-    isAAFailure = StoreOffset + int64_t(StoreSize) <= LoadOffset;
-  else
-    isAAFailure = LoadOffset + int64_t(LoadSize) <= StoreOffset;
-
-  if (isAAFailure)
-    return -1;
-
   // If the Load isn't completely contained within the stored bits, we don't
   // have all the bits to feed it.  We could do something crazy in the future
   // (issue a smaller load then merge the bits in) but this seems unlikely to be
@@ -221,6 +204,18 @@
       StoreOffset + StoreSize < LoadOffset + LoadSize)
     return -1;
 
+  // If the load and store are to the exact same address, they should have been
+  // a must alias.  AA must have gotten confused.
+  // FIXME: Study to see if/when this happens.  One case is forwarding a memset
+  // to a load from the base of the memset.
+
+  // If the load and store don't overlap at all, the store doesn't provide
+  // anything to the load.  In this case, they really don't alias at all, AA
+  // must have gotten confused.  The if statement above ensure the condition
+  // that StoreOffset <= LoadOffset.
+  if (StoreOffset + int64_t(StoreSize) <= LoadOffset)
+    return -1;
+
   // Okay, we can do this transformation.  Return the number of bytes into the
   // store that the load is.
   return LoadOffset - StoreOffset;


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D99648.334565.patch
Type: text/x-patch
Size: 2272 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20210401/afd5668a/attachment.bin>