[llvm-bugs] [Bug 27314] New: Overflows in the computation of the address of invariant loads are not handled.

[via llvm-bugs]

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

            Bug ID: 27314
           Summary: Overflows in the computation of the address of
                    invariant loads are not handled.
           Product: Polly
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Optimizer
          Assignee: polly-dev at googlegroups.com
          Reporter: doerfert at cs.uni-saarland.de
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

Created attachment 16200
  --> https://llvm.org/bugs/attachment.cgi?id=16200&action=edit
IR testcase that shows the problem

The invariant load hoisting and the runtime checks are currently done one after
the other, however that scheme has its limits. The test case attached is
generated from the following C code:

;    int GI[256];
;    void f(int *A, unsigned char c) {
;      int *I = &GI[127];
;      for (int i = 0; i < 10; i++)
;        A[i] += I[(signed char)(c + (unsigned char)1)];
;    }

We correctly disallow c to be 127 as that will trigger an overflow that is not
represented. However, we still preload the invariant load and access it without
knowing if c is 127 or not.

In general I think we have to entangle RTCs and hoisted loads more than they
are right now, especially once we get the "safe" RTCs which track overflows
(patch is almost done).

A different solution would be to disallow hoisting in case there might be an
overflow in the address computation. That will at least make the problem less
likely to occur. Note that it will not solve it completely if we do not check
the current "overflow state" of the RTCs before executing the load.

-- 
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/20160410/fb072afc/attachment.html>