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

Shuxin Yang shuxin.llvm at gmail.com
Mon Mar 4 10:14:24 PST 2013


On 3/4/13 9:27 AM, Nuno Lopes wrote:
>>> 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.

I didn't mix the connects.
you did 1), and involve the ObjectSizeOffsetVisitor::visitPhiNode() from 
working with a single instance to working
for a set of instances.

In similar vein, people come up function for 2). Why 2) is wrong if 1) 
is correct.


>
> 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




More information about the llvm-commits mailing list