similar to: [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:

Tobias, I'm doing something similar (I use LLVM as part of my JIT compiler) and if I remember correctly, LLVM does the correct thing. I think you need to try changing the i64 value to an i32 value. If that doesn't work you could also try replacing the tail call with a normal call. Mark. Tobias wrote: > I'm compiling code which contains indirect function calls > via their

I was told that my writeup lacked an example and details so I reproduced the code that X uses and I was able to boil down the issue to a couple of lines of code. Sorry again for the length of this email. Code was compiled on OpenBSD with clang 3.0-release. ======================================================================== With -O0 which works as X expects:

Hello Mark, I've followed your advice and changed the IR to: %0 = call i32 inttoptr (i32 12345678 to i32 (i32)*)(i32 0) nounwind the call is still indirect. IMHO llc does not call it directly because the address is neither a globalvalue (JIT) nor a external symbol. That's why it uses a fallback mechanism to call it indirectly assuming the address is not constant and is calculated at

Tobias, I've looked into this a bit more. You are right. The confusion arose as I have two versions of my compiler: The ahead-of-time compiler uses symbolic info and does the right thing. The JIT compiler uses runtime addresses (in effect integers) and when I examined the code in the debugger I found that LLVM produces indirect calls, like this: mov $0x8153c8c,%eax call *%eax Sadly,

I finally got all of the 3DNow! instruction intrinsics and builtins into LLVM and Clang, however, while testing them, I've noticed that they produce incorrect results. For example: typedef float V2f __attribute__((vector_size(8))); int main() { V2f dest, a = {1.0, 3.0}, b = {10.0, 3.5}; dest = __builtin_ia32_pfadd(a, b); printf("(%f, %f)\n", dest[0], dest[1]); } Should

Hey Eli, On Thu, Feb 14, 2013 at 5:45 PM, Eli Bendersky <eliben at google.com> wrote: > Hello, > > While investigating one of the existing tests > (test/CodeGen/X86/tailcallpic2.ll), I ran into IR that produces some > interesting code. The IR is very straightforward: > > define protected fastcc i32 @tailcallee(i32 %a1, i32 %a2, i32 %a3, i32 > %a4) { > entry: >

Hi all, I'm toying around with LLVM's GC support and am struggling with the following. I have a little test snippet (a .ll file with IR) that uses llvm.gcroot to mark a GC root, but when I compile it to assembly with llc, followed by generating an executable with gcc I get an error related to exception handling: 22:40|melis at juggle2:~/projects/llvm_gc> cat root.ll %obj = type { i8*,

Hello, While investigating one of the existing tests (test/CodeGen/X86/tailcallpic2.ll), I ran into IR that produces some interesting code. The IR is very straightforward: define protected fastcc i32 @tailcallee(i32 %a1, i32 %a2, i32 %a3, i32 %a4) { entry: ret i32 %a3 } define fastcc i32 @tailcaller(i32 %in1, i32 %in2) { entry: %tmp11 = tail call fastcc i32 @tailcallee( i32 %in1, i32 %in2, i32

I try to generate a human readable .ll file on Linux. I installed llvm-gcc but as I see it can generate only assembly code (-S option). Is there any way to get something like what is generated by llvm online compiler? That's what I get with llvm-gcc -S -emit-llvm hello.c on Ubuntu 10.10: .file "hello.c" .ident "GCC: (Ubuntu/Linaro 4.5.1-7ubuntu2) 4.5.1 LLVM: "

Hello, I have this simple IR: ------------------------------------------------------------------------ define internal i32 @tmp(i32 %x) { entry: br label %entry2 entry2: %x1 = alloca i32 %x2 = alloca i32 %retval = alloca i32 %dummy = alloca i32 store i32 %x, i32* %x1 store i32 %x, i32* %x2 %tmp1 = load i32* %x1 %tmp2 = add i32 %tmp1, %tmp1

>> While investigating one of the existing tests >> (test/CodeGen/X86/tailcallpic2.ll), I ran into IR that produces some >> interesting code. The IR is very straightforward: >> >> define protected fastcc i32 @tailcallee(i32 %a1, i32 %a2, i32 %a3, i32 >> %a4) { >> entry: >> ret i32 %a3 >> } >> >> define fastcc i32 @tailcaller(i32

When you enable -tailcallopt you get support for tail calls between functions with arbitrary stack space requirements. That means the calling convention has to change slightly. E.g the callee is responsible for removing it's arguments of the stack. The caller cannot transitively know the tail callee's tailcallee's requirement. Also care must be taken to make sure the stack stays

Even if you can't implement such an algorithm sanely, ISTM that auto-generating this code from a table (or whatever), and choosing canonical results (to avoid a fixpoint issue), rather than what seems to be hand-additions of every possible set of minimizations on three variables, is still a better solution, no? At least then you wouldn't have human errors, and a growing file that makes

Hi, I have a question on why gcc and llvm-gcc compile the following simple code snippet differently: extern int a; extern int *b; void foo() { int i; for (i = 1; i < 100; ++i) a += b[i]; } gcc compiles this function hoisting the load of the global variable "b" outside of the loop, while llvm-gcc keeps it inside the loop. This results in slower code on the part of

On 19/08/2009, at 4:00 AM, Anton Korobeynikov wrote: > Hello, Nathan > >> or if it should be a configure test, which might be safer. Are there >> any x86 platforms (other than apple) that don't need PLT-indirect >> calls? > Yes, mingw. However just tweaking the define is not enough - we're not Ok, so configure might be the way to go then, maybe something

Hi Arnold, Thanks for the insights. My comments below: On Thu, Feb 14, 2013 at 5:30 PM, Arnold Schwaighofer <aschwaighofer at apple.com> wrote: > When you enable -tailcallopt you get support for tail calls between functions with arbitrary stack space requirements. That means the calling convention has to change slightly. E.g the callee is responsible for removing it's arguments of

Thanks Sean for the reference. I will go through it and see if i can implement it for generic boolean expression minimization. Regards, Suyog On Wed, Aug 13, 2014 at 2:30 AM, Sean Silva <chisophugis at gmail.com> wrote: > Re-adding the mailing list (remember to hit "reply all") > > > On Tue, Aug 12, 2014 at 9:36 AM, suyog sarda <sardask01 at gmail.com> wrote:

Dear guys, I am in need of more of your help. I'm implementing a register allocator, and I am having problems to make it produce correct code. Consider this program here: int main(int argc, char ** argv) { int i, j, sum; i = argv[0][0]; j = argv[0][1]; sum = (i + j) * j; printf("Sum = %d\n", sum); } that maps to this llvm bytecode: entry (0xa785590, LLVM

I've modified llvm to emit vc++ compatible SEH structures for my personality on x86/Windows and my handler works fine, but the only thing I can't figure out is how to call these funclets, they look like: Catch: "?catch$3@?0?m3 at 4HA": LBB4_3: # %BasicBlock26 pushl %ebp pushl %eax addl $12, %ebp movl %esp, -28(%ebp) movl $LBB4_5, %eax