similar to: [LLVMdev] direct calls to inttoptr constants

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'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:

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,

Hi, I've generated a .bc file for a simple program using the clang front end, the human readable output of llvm-dis looks good. Running llc on the bc file generates an assembly file (.s using either att or intel syntax). Now, when I try to generate an executable with gcc (3.4.4 cygwin) I get lot's of errors: $ gcc t.S t.S: Assembler messages: t.S:4: Error: no such instruction: `align

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

The ll file: ; ModuleID = 't.bc' target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-f80:128:128-v64:64:64-v128:128:128-a0:0:64-f80:32:32-n8:16:32" target triple = "i686-pc-win32" @.str = private constant [13 x i8] c"hello world\0A\00" ; <[13 x i8]*> [#uses=1] define i32 @main(i32 %argc, i8** %argv)

On Jan 26, 2010, at 6:31 AM, herz wrote: > Hi, > > I've generated a .bc file for a simple program using the clang front > end, the human readable output of llvm-dis looks good. > Running llc on the bc file generates an assembly file (.s using either > att or intel syntax). > Now, when I try to generate an executable with gcc (3.4.4 cygwin) I > get > lot's of

Hi Duncan, David, Sean. Thanks for your reply. > It'd be interesting if you could find a design that also treated these > the same: > > (B ^ A) | ((A ^ B) ^ C) -> (A ^ B) | C > (B ^ A) | ((B ^ C) ^ A) -> (A ^ B) | C > (B ^ A) | ((C ^ A) ^ B) -> (A ^ B) | C > > I.e., `^` is also associative. Agree with Duncan on including associative operation too.

Well, can I enforce gcc compatible output somehow? I tried playing with the llc flags which didn't help. A possible subtarget for windows might be masm, the msvc compiler and the like. Alex Chris Lattner schrieb: > Anton, > > This is a because the "windows" x86 target defaults to intel syntax asm. I'm not even sure what the "windows" subtarget is if not for

Hi LLVM and GCC developers, My sincere thanks will goto: * Duncan, the core developer of llvm-gcc and dragonegg http://llvm.org/devmtg/2009-10/Sands_LLVMGCCPlugin.pdf * David, the innovator and developer of GCC https://dmalcolm.fedorapeople.org/gcc/global-state/requirements.html and others who give me kind response for teaching me patiently and carefully about how to migrate GCC v4.8.x to

Hi, I tried that before, it produces .text ALIGN 16 .globl _main _main: ; @main ; BB#0: ; %entry subl $20, %esp movl $0, 16(%esp) movl 24(%esp), %eax movl %eax, 12(%esp) movl 28(%esp), %eax movl %eax, 8(%esp) movl $($_.str),

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:

Anton, This is a because the "windows" x86 target defaults to intel syntax asm. I'm not even sure what the "windows" subtarget is if not for mingw or cygwin. Does it make sense to remove the "Windows" target and have "i686-pc-win32" just be a synonym for mingw? -Chris On Jan 27, 2010, at 1:32 AM, herz wrote: > The ll file: > > ; ModuleID

Sorry I missed that important detail. The relevant part of the command line is: -cc1 -S -triple i386-pc-win32 I don't expect it matters if it's for Windows or Linux in this case. On Fri, Sep 14, 2018 at 9:16 PM David Blaikie <dblaikie at gmail.com> wrote: > Can't say I've observed that behavior (though I'm just building from > top-of-tree rather than 6.0,

When I increased COLS to the point where the loop could no longer be unrolled, the selection dag code generator generated effectively the same code as the default X86 code generator. Lots of redundant imul/movl/addl sequences. It can't clean it up either. Only unrolling all nested loops permits it to be optimized away, regardless of code generator. Jeff Cohen wrote: > I noticed

Hi everyone, I found that LLVM generates redundant code when calling functions with constant parameters, with optimizations disabled. Consider the following C code snippet: int foo(int x, int y); void bar() { foo(1, 2); foo(3, 4); } Clang/LLVM 6.0 generates the following assembly code: _bar: subl $32, %esp movl $1, %eax movl $2, %ecx movl $1, (%esp) movl $2, 4(%esp) movl %eax, 28(%esp) movl

In my back-end I'd like to be able to pass dummy values to functions that ignore them. The following code: declare i32 @foo(i32, i32, i32) define void @bar() nounwind { entry: %call = call i32 @foo(i32 8, i32 6, i32 undef) ret void } ends up generating (using llc -O3): bar: # @bar # BB#0: #

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 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: