[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