[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