llvm dev - Apr 2015 - [LLVMdev] enhancing tbaa alias information for array accesses.

Hi all,

I am looking into fixing a wrong-code aliasing issue related to unions.
As this will likely change the metadata format, I am also trying to incorporate
a fix/enhancement for the following problem:

// array member
// ------------
struct S00 {
  char mC_0;
  short mS_1;
  int mI_2;
  int mI_3;
};
struct S03 {
  short mS_0;
  struct S00 mS00_1[4];
  short mS_2;
};

void test_s03c(struct S03* a, struct S03* b)
{
  a->mS00_1[0].mI_2=1;
  b->mS00_1[1].mI_2=2;

  // c++11:   NoAlias
  // llvm:    MayAlias ******** performance
  // future:  NoAlias
}

(Also see http://lists.cs.uiuc.edu/pipermail/cfe-dev/2015-March/042110.html )

Today, we lose the struct S03 information in the tbaa description (the tbaa just
points to S00) . Even if it would keep this information,
it is unlikely (in the more general case) that we can compute in clang the exact
offset of the access.
After some optimization passes on the llvm-ir, we might know, but not at the
moment that we generate the
metadata.

So: for tbaa, these might overlap, for basic aa, they also can overlap as basic
aa can only make conservative assumptions about
the 'a' and 'b' pointers.

The problem is that in basicaa, we don't know that 
(1) either a==b or   or |(intptr)a--(intptr)b| >= sizeof(struct S03).

Somehow basicaa and tbaa should be able to work together (in stead of one after
the other)
such that basicaa can assume that (1) holds. Then basiccaa can get this right.

Any suggestions ?

One solution, as Daniel mentioned would be to add tbaa information to the gep
(and somehow let basicaa use it to deduce that the constrain (1) is true).
Would that be the way forward ? (that solution would at least be orthogonal to
the solution for the other issues I am trying to solve.)

Thanks,

Jeroen Dobbelaere