[PATCH] More precise aliasing for char arrays

[Arthur O'Dwyer]

Hi Sanjin,

Your test case is

    int *p;
    typedef struct {
      char a;
      char b[100];
      char c;
    } S;

    S x;

    void func1 (char d) {
      for (int i = 0; i < 100; i++) {
        x.b[i] += 1;
        d = *p;
        x.a += d;
      }
    }

It seems like you want the compiler to hoist the read of `*p` above
the write to `x.b[i]`. But that isn't generally possible, is it?
because the caller might have executed

    p = &x.b[3];

before the call to func1.

The test case in Bug 20074 is different: in that case, `aStruct` and
`aStruct->c` really can't alias (at least, not in any way that I can
figure out), because `aStruct` (unlike `*p`) is a named variable.

–Arthur



On Wed, Jun 25, 2014 at 2:21 PM, Sanjin Sijaric <ssijaric at codeaurora.org> wrote:
> Hi,
>
>
>
> The following patch aims to address bug #20074, and similar ones.  The
> problem is that accesses to elements in constant-sized char arrays end up
> annotated with TBAA tags that have base as “omnipotent char”, so they’ll
> alias with pointers other than pointers to char.  This prevents some
> optimizations, such as removing redundant loads in bug #20074.  Or in the
> case of the attached test cases, it prevents hoisting of loads from loops.
> The fix is to change the base type to that of “char” if we know we are
> dealing with constant sized char arrays.   In effect, this mimics the
> behaviour of aliasing generated for other types of arrays (e.g. the base
> type is not the “omnipotent char”, but there is a path that eventually leads
> to it).  I didn’t attempt to address VLAs.
>
>
>
> Can someone please review?
>
>
>
> Thanks,
>
> Sanjin
>
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>