[LLVMdev] compare two GEP instructions operand by operand

John Criswell
Tue, 30 Aug 2011 15:35:20 -0000

On 8/30/11 10:10 AM, Jimborean Alexandra wrote:
> Hi,
>
> I have a question regarding the GEP instruction. Is it correct to
> consider that two GEP instructions compute the same memory address if
> and only if all their corresponding fields are equal?

It's more complicated than that.

First, all the operands of the GEP must be dynamically identical for all
executions.  Second, the *type* of the pointer operands must be identical.

The first requirement means that you can't just statically look at the
SSA values and figure out if they're identical.  Consider the following
psuedo-LLVM IR/C code example:

while (x > 0) {
     y = gep p, 0, x
}

z = gep p, 0, x

The two GEPs have identical, static SSA operands but won't compute the
same address because one is in a loop, and the other is not.  You have
to tack on some additional requirements, like requiring that y and z be
in the same basic block.  In short, you have to take control-dependence
into account somehow.

The second requirement handles issues like the following:

p = global int
y = gep p, 0, x
z = gep cast p to char *, 0, x

Note that requirement 1 is fulfilled, but because p is an int * when
calculating y and a char * when calculating z, y and z will not be the
same values.

-- John T.


>
> For instance, for a two-dimensional array of integers, can we have two
> GEP instructions that are equal?
>
>   %arrayidx = getelementptr [10 x [30 x i32]]* @main.B, i64 0, i64 0,
> i64 %tmp157
>
>   %tmp = load i32* getelementptr inbounds ([10 x [30 x i32]]* @main.B,
> i64 0, i64 3, i64 10), align 8
>
> although their corresponding indices are different? For instance if
> %tmp157 goes out of the bounds of the line 0 and computes the address
> of the 10th element in line 3.
>
>
> Thank you,
> Alexandra
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110830/c600aa99/attachment.html>