[LLVMdev] Load from abs address generated bad code on LLVM 2.4

Óscar Fuentes ofv at wanadoo.es
Mon Jan 19 10:18:48 PST 2009


Andrew Haley <aph at redhat.com> writes:

> Óscar Fuentes wrote:
>> The following message is a courtesy copy of an article
>> that has been posted to gmane.comp.compilers.llvm.devel as well.
>> 
>> Andrew Haley <aph at redhat.com> writes:
>> 
>>> This is x86_64.  I have a problem where an absolute memory load
>>>
>>> define i32 @foo() {
>>> entry:
>>>         %0 = load i32* inttoptr (i64 12704196 to i32*)          ; <i32> [#uses=1]
>>>         ret i32 %0
>>> }
>>>
>>> generates incorrect code on LLVM 2.4:
>>>
>>> 0x7ffff6d54010:	mov    0xc1d9c4(%rip),%eax        # 0x7ffff79719da
>>> 0x7ffff6d54016:	retq
>> 
>> IIRC, one workaround is to use a GlobalValue instead of a IntToPtr on a
>> Constant.
>
> Err, how?  I can't figure out how to do it.  The only documentation for
> GlobalValue describes it as a superclass of GlobalVariables and Functions.

IIRC, the stuff I used was something like...

GlobalVariable *gv = new GlobalVariable( /* your pointer type */,
                         other required parameters...);
AddGlobalMapping(gv, your_pointer_value); // i.e. (void*)0x938742

then, where you use

  Constant* thp = ConstantExpr::getCast(Instruction::IntToPtr,
  your_pointer_value, /* i.e. 0x938742 */
  /* your pointer type */);

/* Now use thp */

change it to

/* Now just use gv */

GetGlobalValueAtAddress may be useful for housekeeping.

If something is wrong or not as effcient as it could be, I hope someone
on the mailing list will correct me.

-- 
Oscar




More information about the llvm-dev mailing list