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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
