[PATCH] D31885: Remove TBAA information from LValues representing union members

Hal Finkel via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Fri Apr 14 10:09:56 PDT 2017


hfinkel added a comment.

> I'm not sure about the solution to #2, because i thought there were very specific points in time at which the effective type could change.

I think this is a key point. I'm not sure that there are specific points that the frontend can deduce:

  union U {
    int i;
    float f;
  };
  
  void bar1(int *i) {
    *i = 0; // we just reset the type here
  }
  
  void bar2(float *f) {
    *f = 0.0f; // we just reset the type here too
  }
  
  void foo(U *u) {
    bar1(&u->i);
    bar2(&u->f);
  }

Even if the union has structs instead of scalar types, I'm not sure that changes the situation. There certainly are situation where you can't silently change the types of objects in C++ just by starting to write a to differently-typed object at the same location, but I think that using this property relies on having some lifetime information for the objects in question, and so AA would need to be able to use this lifetime information to do more. This seems like an orthogonal issue (i.e. we can always add TBAA write <-> write ability in the presence of such lifetime information as an additional feature). Maybe I'm missing something...

> As we've repeatedly said, memory locations and pointers don't really have tbaa info, instructions do.

I agree (and I think we'll need to do this in order to handle such lifetime information (and there are also issues around noalias handling that are relevant)).


Repository:
  rL LLVM

https://reviews.llvm.org/D31885





More information about the cfe-commits mailing list