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

Nuno Lopes nunoplopes at sapo.pt
Sun Mar 3 14:17:14 PST 2013


> I have to agree with Shuxin here. The LangRef says about the semantics of 
> "llvm.objectsize.i32/i64":
>
> "The llvm.objectsize intrinsic is designed to provide information to the 
> optimizers to determine at compile time whether a) an operation (like 
> memcpy) will overflow a buffer that corresponds to an object, or b) that a 
> runtime check for overflow isn’t necessary. An object in this context 
> means an allocation of a specific class, structure, array, or other 
> object."
>
> "The llvm.objectsize intrinsic is lowered to a constant representing the 
> size of the object concerned. If the size cannot be determined at compile 
> time,llvm.objectsize returns i32/i64 -1 or 0 (depending on the min 
> argument)."
>
> Emphasis: "An object in this context means an allocation of a specific 
> class, structure, array, or other object."
>
> To me this can be clearly interpreted as a requirement to point to one 
> "identified underlying object" in LLVM terms. A front end could now assume 
> that if "llvm.objectsize.i32/i64" returns a value other than the failurer 
> value it is guaranteed that the pointer value points to one underlying 
> object and not two.

Let me give an example:

%p1 = malloc(42);
%p2 = malloc(42);
%p3 = phi(%p1, %p2);
%size = @llvm.objectsize(%p3);

The patch I commited enables instcombine to replace %size  with the constant 
42.
I fail to see why that transformation is incorrect.  While it's true that we 
don't know to which object %p3 will point to at run time, we know that its 
size will be 42.  Of course, if we had %p2=malloc(3)', then we couldn't do 
this constant propagation.
For the analysis of objectsize, it's safe to look to a superset of the 
objects pointed-to by the input pointer.


Shuxin: I'm not breaking any assumption here.  If you notice, we already do 
a similar analysis for select instructions.  Phi nodes were not processed 
because nobody (I mean, me) implemented the code.
I agree BasicAA could use more comments. I'll add a comment there.

Nuno 




More information about the llvm-commits mailing list