<div dir="ltr">This looks awfully familiar to a bug that my patch fixes.  I tried a similar approach earlier in <a href="http://llvm-reviews.chandlerc.com/D2060">http://llvm-reviews.chandlerc.com/D2060</a> but instead settled on <a href="http://llvm-reviews.chandlerc.com/D2093">http://llvm-reviews.chandlerc.com/D2093</a><div>
<br></div><div>I have a strong feeling that my second patch will fix your bug (and potentially others).</div><div><br></div><div> -- </div><div>David Majnemer</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Wed, Nov 6, 2013 at 4:07 PM, Bill Wendling <span dir="ltr"><<a href="mailto:isanbard@gmail.com" target="_blank">isanbard@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Chandler et al,<br>
<br>
This is a potential patch for PR17158. What seems to be happening is that GVN gets ahold of the file, it tries to determine if the initializer for x7 can be folded into the use. Because of SROA, it's doing some weird pointer things involving the structure padding. So for instance, the structure is this:<br>

<br>
        { { i32, i8, [3 x i8] }, i8, [3 x i8] }<br>
<br>
It copies over the 'i32' and 'i8' from the inner structure. SROA then generates a memcpy from the [3 x i8] in the inner structure to the end of the outer structure, which sounds okay. However, GVN looks at the access to the outer 'i8' element, but because of SROA, that element is generated as the element of the inner [3 x i8] at offset 3. This is of course outside of the array. Because it's padding, the value it returns is undef. Thus it folds the value of '0' into the call to 'printf'.<br>

<br>
Got that so far? ;-)<br>
<br>
Here's a patch I have. It basically makes sure that, if the constant it's looking at is an array, the index into that array does not go outside of that array. If that happens, then there's something complex going on and the constant folding isn't safe anymore.<br>

<br>
What do you think? Is this the correct solution?<br>
<br>
-bw<br>
<br>
Run the attached t.ll with "opt -sroa -instcombine -gvn", generate the .s file, and run it. It should print '1', but instead prints '0'.<br>
<br>
diff --git a/lib/Analysis/ConstantFolding.cpp b/lib/Analysis/ConstantFolding.cpp<br>
index e093631..527fa80 100644<br>
--- a/lib/Analysis/ConstantFolding.cpp<br>
+++ b/lib/Analysis/ConstantFolding.cpp<br>
@@ -1145,7 +1145,11 @@ Constant *llvm::ConstantFoldLoadThroughGEPConstantExpr(Constant *C,<br>
   // Loop over all of the operands, tracking down which value we are<br>
   // addressing.<br>
   for (unsigned i = 2, e = CE->getNumOperands(); i != e; ++i) {<br>
-    C = C->getAggregateElement(CE->getOperand(i));<br>
+    Constant *Offset = CE->getOperand(i);<br>
+    if (const ArrayType *AT = dyn_cast<ArrayType>(C->getType()))<br>
+      if (AT->getNumElements() <= cast<ConstantInt>(Offset)->getZExtValue())<br>
+        return 0;<br>
+    C = C->getAggregateElement(Offset);<br>
     if (C == 0)<br>
       return 0;<br>
   }<br>
<br>
<br>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
<br></blockquote></div><br></div>