<html>
<head>
<base href="https://llvm.org/bugs/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW --- - [Correctness] Basic Alias Analysis failed to recognize that two GEPs alias"
href="https://llvm.org/bugs/show_bug.cgi?id=24468">24468</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>[Correctness] Basic Alias Analysis failed to recognize that two GEPs alias
</td>
</tr>
<tr>
<th>Product</th>
<td>libraries
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>Global Analyses
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>qcolombet@apple.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=14731" name="attach_14731" title="File to reproduce with opt">attachment 14731</a> <a href="attachment.cgi?id=14731&action=edit" title="File to reproduce with opt">[details]</a></span>
File to reproduce with opt
The problem can be illustrated with the following C code (though use the LLVM
IR and opt to reproduce):
#include <stdio.h>
#define A 0x2aaaaaaa
#define B 0x2aaaaaab
static unsigned int P = A;
static unsigned int Q = B;
int main(int argc, char **argv) {
unsigned char t[3], u[3];
t[3 * (P - A)] = 42;
u[3 * (Q - B)] = 99;
printf("%u %u\n", t[0], u[0]);
return 0;
}
Because of the optimizations (i.e., instcombine) we end up with basically two
accesses:
store @U[3*Q + BigCst] ; <-- with wrapping semantic
load @U[0]
The problem is that basicaa failed to recognize that 0 and 3*Q + BigCst may be
equal. Indeed, basicaa thinks that 3*Q is positive and thus can only add up to
BigCst, whereas the related add in the IR has wrapping semantic. So, in the
worse case, it thinks that the store is at BigCst from the start of the array,
whereas it can be 0.
To reproduce:
opt -basicaa -gvn repro.ll -o ko.ll
clang ko.ll -o a.out
./a.out
Result:
42 0
Expected:
42 99
Note:
Reverting r221876 fixes the problem.
The problem is basically in GetLinearExpression, where we sum all the constant
offset whereas some are not guarantee to contribute that amount to the final
offset (because of wrapping).
A trivial fix could be to mark the constant offset as unknown, but that is
overly conservative and probably not better than just reverting 221876.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>