similar to: [LLVMdev] Interesting optimization failure.

Hi Richard, > I have been working on using arrays and structs as first class objects. good to hear! The example doesn't make use of that though, does it? > I have this small function: > > int main() > { > char ar[10] = "12"; > return ar[4]; > } ... > define i32 @main() nounwind { > entry: > ret i32 49 > } > Here I get

Hi All, I have a C code: ////////////////////////////// #include "stdio.h" int main () { putchar('a'); return 0; } llvm-gcc -emit-llvm, I got //////////////////////////////////////// ; ModuleID = 't1.bc' target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32" target triple

Hi all, I've been exploring thread local globals in llvm and as part of this investigation I ran llc -march=cpp over a trivial llvm bc file which uses thread local storage for a global. For some reason llc -march=cpp seems to ignore the thread_local and produce code to create a standard global. Is this expected behaviour, a known limitation, or otherwise? Thanks in advance. Details are as

Thanks,Cheers! I found the problem is that the "Function *call_print" using the same name as the “class call_print”, which made the compiler wrongly resolved the call_print type! But I got another problems. I successfully compile the pass and I can insert the call printf (C Lib function) instructions in the LLVM IR(eg: call.bc). If the call.bc didn't contain call printf

Hi, This patch raises selected instructions to function calls. I've dome some preliminary testing and I works: ; ModuleID = 'raise.o' target datalayout = "e-p:32:32-i1:8:0-i8:8:0-i16:16:0-i32:32:0-i32:32:0-i64:32:0-f32:32:0-f64:32:0-f96:32:0-v64:64:64-v128:128:0-a0:0" target triple = "i386-pc-linux-gnu" define i32 @main(i32, i8**, ...) nounwind { entry:

On Aug 8, 2009, at 8:37 AM, Richard Pennington wrote: > Hi, > > This patch raises selected instructions to function calls. I've dome > some preliminary testing and I works: Out of curiosity, why do you want this? -Chris > > ; ModuleID = 'raise.o' > target datalayout = "e-p:32:32-i1:8:0-i8:8:0-i16:16:0-i32:32:0- >

Hi: When I try to execute lli -force-interpreter=true hello.bc, it gave the following error: LLVM ERROR: Tried to execute an unknown external function: i32 (i8*)* puts I think the error is because C library is not being linked with the byte code, but I was not able to find any helpful instruction in lli's document. Can you please teach me how to do it? Thanks Xu The hello.bc is

Do you compile this as C? In C, unlike in C++, empty parenthesis do not mean "no arguments", they mean "no prototype", which is typically treated the same way as varargs in calling conventions. To declare function with no arguments do typedef void (*FP)(void); Eugene On Wed, Apr 21, 2010 at 10:22 PM, Arushi Aggarwal <arushi987 at gmail.com> wrote: > Hi all, > >

Hi all, I had the following function that used function pointers with void arguments, typedef void (*FP)(); void foo() { printf("hello world from foo\n"); } int main() { FP fp; fp = foo; (*fp)(); } The corresponding bitcode, with no optimizations is target datalayout =

Xu Yang wrote: > Hi: > > When I try to execute lli -force-interpreter=true hello.bc, it gave the > following error: > > LLVM ERROR: Tried to execute an unknown external function: i32 (i8*)* puts > > I think the error is because C library is not being linked with the byte > code, but I was not able to find any helpful instruction in lli's document. > > Can you

Hi all, I'm working for translating dex bytecode to LLVM IR In order to communicate with Android interpreter, The work have to add data below some instructions I want to use inline assembly to add data. Thus, I wrote a little program to find out the related LLVM IR int main() { asm(".long 0x12345678"); return 0; } and I use clang to translate it into bitcode It's the

Hi, I found that machine dead code elimination, does not respect the calling convention of alpha and eliminates r16, which was set correctly during code generation. I verified it with -print-after-all. Does anybody have a patch for this? On Wed, Jun 29, 2011 at 11:12 AM, Ankit Sethia <asethia at eecs.umich.edu>wrote: > Hi All, > > I am using llvm-2.9 to cross compile to alpha. I

On Jan 6, 2010, at 1:12 PM, fima rabin wrote: > I am trying to compile a little intrinsic function for my machine. Here is a dump from clang-cc with --emit-llvm option: > ===================== > > ; ModuleID = 'foo.c' > target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32" >

I'm generating code for a target that only supports i32 natively. My front end is generating VAARG for accessing varargs parameters. The problem is that I get an assert when I compile this: #include <stdarg.h> int main(va_list ap) { typedef double type; type tmp; tmp = va_arg(ap, type); } Bitcode: ; ModuleID = 't0056.bc' target datalayout =

I am trying to compile a little intrinsic function for my machine. Here is a dump from clang-cc with --emit-llvm option: ===================== ; ModuleID = 'foo.c' target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32" target triple = "i386-pc-linux-gnu" @main.i = internal global i32

Hi All, I am using llvm-2.9 to cross compile to alpha. I know that alpha is in experimental stage, but i can not get even the "Hello World" program to run on it. Here is what happens, the bitcode file for the hello world program is as follow: ; ModuleID = 'hello.bc' target datalayout =

Hi, Can people suggest how this is solved for other ISAs? This happens only for Alpha and not for x86-64. The register 16 does not have any uses within that function, but is used inside puts. So Machine DCE thinks it is dead code. On Wed, Jun 29, 2011 at 4:20 PM, Ankit Sethia <asethia at eecs.umich.edu>wrote: > Hi, > > I found that machine dead code elimination, does not respect

Works for me: [jhereg:~/tmp] echristo% /Volumes/Data/builds/build-llvm/Debug+Asserts/bin/clang -S -emit-llvm foo.cpp [jhereg:~/tmp] echristo% lli foo.s testing [jhereg:~/tmp] echristo% llvm-gcc -S -emit-llvm foo.cpp [jhereg:~/tmp] echristo% lli foo.s testing the first is using top of tree clang. The second is using an llvm-gcc on my OS. What versions are you using? -eric On Feb 6, 2012, at

Hi, The lli interpreter crashed for the following case: ; ModuleID = 'x.c' target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32" target triple = "i686-pc-linux-gnu" define i32 @main() { entry: %retval = alloca i32 ; <i32*> [#uses=2] %tmp = alloca i32 ;

Hi Eric, Here's the C code (example.c): include <stdio.h> int main() { printf("testing\n"); } Here's the LLVM IR (from llvm-gcc): ModuleID = 'example.c' target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64" target triple =