llvm dev - Feb 2009 - [LLVMdev] direct calls to inttoptr constants

I'm compiling code which contains indirect function calls
via their absolute addresses, which are known/fixed at compile-time:

pseudo c code:
int main() {
int (* f)(int) = (int (*)(int))12345678;
return (*f)(0);
}

the IR looks like:
define i32 @main() nounwind {
entry:
%0 = tail call i32 inttoptr (i64 12345678 to i32 (i32)*)(i32 0) nounwind
ret i32 %0
}

on X86 llc 2.4 compiles this to:
 .text
 .align 16
 .globl main
 .type main, at function
main:
 subl $4, %esp
 movl $0, (%esp)
 movl $12345678, %eax
 call *%eax
 addl $4, %esp
 ret
 .size main, .-main

 .section .note.GNU-stack,"", at progbits

take a look at:
movl $12345678, %eax
call *%eax

does anyone know a way to cause llc to call the address directly?
hints where to start patching the codegen are also welcome.

expected assembly:
call *12345678

best regards
tobias

On Feb 10, 2009, at 4:51 AM, Tobias wrote:
> I'm compiling code which contains indirect function calls
> via their absolute addresses, which are known/fixed at compile-time:
> call *%eax
>
> does anyone know a way to cause llc to call the address directly?
> hints where to start patching the codegen are also welcome.
lib/Target/X86/X86InstrInfo.td, search for call and CALL.  The problem  
is that the instruction only allows for 32-relative addresses.  The  
form:

   call *0x20

isn't always valid as a 32-bit relative address.  If you place that  
instruction at 1<<60, the destination is more than 1<<32 away.

If you want to say something about your model, say, all code is in the  
first 2bg, then, the instruction would be allowed.  Problem is, I  
suspect there isn't enough model support for this, or your not using it.