[llvm] r176408 - recommit r172363 & r171325 (reverted in r172756)

[Nuno Lopes]

>> Shuxin: I'm not breaking any assumption here.
> If you don't think you break the assumption,  tell us your immediate 
> reaction to
> the class name "ObjectSizeOffsetVisitor".
>
> It seem so odd to me that  xxx_ObjectWhatever() return a meaningful value 
> however we have no idea which
> object it is talking about.
>
> >If you notice, we already do a similar analysis for select instructions.
> Show me the code.
> On the other hand,  there are some code showing similar usage
> dose not necessarily mean that piece of code is correct, or it is good 
> practice to write the code this way.
>
> This is contrived usage of these functions:
>   p1 = &object1.field1
>   p2 = &object2.field2
>   p3 = phi(p1, p2);
>
>   get-object-offset() would return offset(object.filed1).  the optimizer 
> randomly take object1 as
> the "underlying object", and further analysis reveals that the location of 
> &object1.field1 is either used as
> char or int32, a contrived type-based alias alias would mistakenly make a 
> conclusion that *p3
> will not alias a load of floating point type, which could be wrong because 
> object2.field2 could be of fp type.

You are mixing two concepts here:
 1) Compute the size of an object pointed-to by a pointer
 2) Identifying to which object a pointer points to.

For some reason you are assuming that 1) implies 2), which is not correct 
(nor /vice versa/).
Therefore, the "aggressive" alias analysis you propose above doesn't make 
sense.

FYI, the semantics of @llvm.objectsize I've been describing matches exactly 
that of gcc's __bultin_object_size().  If there's a bug somewhere, that's in 
the documentation.

Nuno