[llvm-bugs] [Bug 24468] New: [Correctness] Basic Alias Analysis failed to recognize that two GEPs alias

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=24468

            Bug ID: 24468
           Summary: [Correctness] Basic Alias Analysis failed to recognize
                    that two GEPs alias
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Global Analyses
          Assignee: unassignedbugs at nondot.org
          Reporter: qcolombet at apple.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

Created attachment 14731
  --> https://llvm.org/bugs/attachment.cgi?id=14731&action=edit
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20150815/2e94cdba/attachment-0001.html>