[LLVMdev] print the memory address computed by getelementptr

John Criswell criswell at illinois.edu
Wed Jul 20 08:08:06 PDT 2011

On 7/20/11 10:02 AM, Jimborean Alexandra wrote:
> Hi,
> I want to print the memory locations computed by getelementptr. As I 
> understood, getelementptr does not access the memory, but it contains 
> the address it computes. I want to print these addresses at runtime 
> (or process them).  So, I try to build a function that takes as 
> argument a pointer and prints its value. And to call this function, by 
> sending the gep instruction as a parameter.

All you really need to do here is to cast the result of the 
getelementptr value to the type of the parameter of your function.  In 
this case, you need to insert a ptrtoint instruction that takes the GEP 
and casts it to an i64.

That said, instead of casting the GEP to an i64, it would be better if 
your run-time function took a void *.  In LLVM IR, a pointer to an i8 is 
a void *, and so you could insert a bitcast of the GEP to an i8 * 
instead of casting it to an i64.  That way, you don't have to worry 
about the pointer size if you start using your code on both 32-bit and 
64-bit targets.

-- John T.

> Surely, I obtain an error for a type mismatch. Can I declare the 
> function as taking an int64 as parameter and then (somehow) sending 
> the value computed by getelementptr?
> declare void @myFunction ( i64 )
> %tmp22 = getelementptr inbounds %struct.linked* %tmp21, i32 0, i32 1
> %tmp = convert_tmp22_to_i64_to_get_the_value_of_the_pointer
> call void @myFunction(i64 %tmp)
> Or could you suggest a better method to get the value computed by 
> getelementptr ?
> Thanks,
> 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/20110720/b6cd745e/attachment.html>

More information about the llvm-dev mailing list