[PATCH] More precise aliasing for char arrays

Sanjin Sijaric ssijaric at codeaurora.org
Wed Jun 25 15:26:53 PDT 2014


Hi Arthur,

Here, "p" is a pointer to int, whereas b is a char array.  Wouldn't "p = &x.b[3];" break ansi aliasing rules?  If "p" were a pointer to char, then the hoisting shouldn't happen.

Thanks,
Sanjin

-----Original Message-----
From: Arthur O'Dwyer [mailto:arthur.j.odwyer at gmail.com] 
Sent: Wednesday, June 25, 2014 3:15 PM
To: Sanjin Sijaric
Cc: cfe-commits
Subject: Re: [PATCH] More precise aliasing for char arrays

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
>





More information about the cfe-commits mailing list