[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