similar to: [LLVMdev] Re: Qustion about LLVM docs (fwd)

Hello again, I'm exploring llvm's intermediary representation with this code: //////////////////////////////////// %.LC0 = internal constant [13 x sbyte] c"hello world\0A\00" declare int %puts(sbyte*) implementation int %main() { %cast210 = getelementptr [13 x sbyte]* %.LC0, long 0, long 0; call int %puts(sbyte* %cast210) ret int 0 }

I just built LLVM 2.0 on Windows with Visual C++ 2005. After a few tweaks, it produced several nice .exe files. I tried to compile a simple Hello-World program as given in the documentation: -------------------------------------------------------------------------------------- ; Declare the string constant as a global constant... %.LC0 = internal constant [13 x i8 ] c"hello

lli executed the bytecode corresponding to test_3.0_ml.ll without a failure, even though Function() is accessing an invalid memory address. The original code is in test_3.0.c, and the malloc() in Create() has been replaced by alloca() in test_3.0_ml.ll. I expected lli to segfault or similar when testing my code. Are my assumptions erroneous? -------------- next part --------------

Hello, I'm playing around with the llvm-tools. On linux everything worked as expected: I downloaded and compiled the llvm-source. Assembled (llvm-as) and linked (llvm-ld) a hello_world program and executed it successfully. For windows I have downloaded the compiled mingw32-binaries: http://llvm.org/releases/2.2/llvm-2.2-x86-mingw32.tar.bz2 I used the following hello_world program from the

Volodya, I think you may need to update your CFE and rebuild. I compiled the test using my local build and I didn't get the results you see below. I'm also very surprised to see this output. The first %tmp.11 should have been %tmp.1 .. not sure how it got corrupted. In any event, the attachment is obviously generated by code that runs quite differently because the virtual register names

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, Is there a way to modify the string such as char a or char b? Could I use the way like "Replace an instruction with another Value" in Programm Manual? In fact, what I am interested in is string with visible expression, not all string, and I am trying to hide the orignal string by using simple way like XOR.. Is there a way to reorder the basic blocks? Thanks. Qiuyu C Source

Hi, I am trying to assemble a preety simple program, but the assembler is giving parse errors: =========================== %.LC0 = internal constant [17 x sbyte] c"Hello World %d \0A\00" %.LC1 = internal constant [17 x sbyte] c"yyyyyyyyyyyyyyy\0a\00" declare int "puts"(sbyte*) int "main"() { %cast1 = getelementptr [17 x sbyte]* %.LC0, long 0, long 0

Hi, > On Mon, 27 Sep 2004, Zhang Qiuyu wrote: > > > Is there a way to modify the string such as char a or char b? Could I > > use the way like "Replace an instruction with another Value" in Programm > > Manual? In fact, what I am interested in is string with visible > > expression, not all string, and I am trying to hide the orignal string > > by

I noticed that fourinarow is one of the programs in which LLVM is much slower than GCC, so I decided to take a look and see why that is so. The program has many loops that look like this: #define ROWS 6 #define COLS 7 void init_board(char b[COLS][ROWS+1]) { int i,j; for (i=0;i<COLS;i++) for (j=0;j<ROWS;j++) b[i][j]='.';

I have an objective-c file, bar.m, that I try to process in the following way generating the error shown below. Any help would be appreciated. I suspect the error is in the first few lines of output. thanks, Todd > cfrontend-g++ -o bar.bc bar.m > llvm2cpp -o bar.cpp bar.bc > g++ -c bar.o bar.cpp > ld -o bar bar.o -l objc -l LLVMCore -l LLVMSupport -l LLVMSystem > ./bar Global

>Right. This looks like it's just a simple bug in llvm2cpp. >CppWriter.cpp:698 contains: > > if (CA->isString() && CA->getType()->getElementType() == >Type::SByteTy) { > Out << "Constant* " << constName << " = ConstantArray::get(\""; > printEscapedString(CA->getAsString()); > //

Currently, Structure layout is left to targets, which implement them according to the ABI of that platform. While this is fine for most structures, it makes packed structures very ugly. All fields in a packed type must be converted to byte arrays with casts to access fields, which bloats accesses and obsfucates the types. First class support for packed types would clean up the generated code

Hi , I got a few for writing a pass. 1) Is it possible to use input parameters in command line ? For example, we got our own pass, ie. HELLO opt -load ../../Debug/lib/libHELLO.so -HELLO < hello.bc From the above command line, could we use some input parameter and we can read those parameter in Pass routine? 2) For splitting BB, the way what I did is to pick up instruction

LLVM, I am trying to equate two dsnodes across call boundries. On the Caller side we have an operand of form: sbyte * getelementptr ([20 x sbyte]* %.LC0, long 0, long 0) using getNodeForValue() yields a NULL pointer. On the Callee, the parameter is of form: sbyte * S and getNodeForValue works fine. Is there something special that must be done to access DNodes accessed using GEP? Thanks,

On Nov 7, 2007, at 6:10 PM, Antony Blakey wrote: > Hi, > I'm experimenting with using LLVM to generate dynamic FFI bridges > in VisualWorks Smalltalk. LLVM is an amazing thing! I'm going from > dynamically generated assembler source to machine code, and I have > that all working, copied from the llc tool and the JIT example. I > have two questions: > > 1. What

On Thu, 16 Dec 2004, Markus F.X.J. Oberhumer wrote: > On Thursday 16 December 2004 06:22, Chris Lattner wrote: >> On Thu, 16 Dec 2004, Markus F.X.J. Oberhumer wrote: >>> More problematic is the use of unsigned instead of size_t in many llvm >>> places - how does the the following file big_array.c compile on your >>> current 64-bit targets: >> >>

I'm trying to insert a call to fprintf(stderr, ...). I've looked at the emitted assembly from llvm-gcc, and it consists of a LoadInst (of stderr) and CallInst. It looks like this: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %tmp.1 = load %struct._IO_FILE** %stderr ; ty=%struct._IO_FILE* %tmp.0 = call int (%struct._IO_FILE*, sbyte*, ...)* %fprintf(%struct._IO_FILE* %tmp.1, sbyte*

Well, the complexity only occurs on x86, other archs are simpler. Since this is not used much outside the c library, I can work around it in the library and be satisifed with the simple case. Oh, I suppose I should mention what I was working on. I made a syscall intrinsic with codegen for linux/x86. It seemed a missing peice in having a pure llvm compiled userland (mostly, being able to have a

Hi, I'm experimenting with using LLVM to generate dynamic FFI bridges in VisualWorks Smalltalk. LLVM is an amazing thing! I'm going from dynamically generated assembler source to machine code, and I have that all working, copied from the llc tool and the JIT example. I have two questions: 1. What optimization passes, if any, should I run on the module before I pass it to the