search for: pointersize

Thx again Evan for the review. Here's a new patch for the JIT in itself. The major changes are: 1) A JITMemoryManager now has a flag saying "I require to know the size of what you want to emit" 2) DwarfJITEmitter is augmented with GetSize* functions 3) JITEmitter::startFunction checks if the JITMemoryManager requires to know the size. If so, it computes it and gives it through the

...StartFunction, EndFunction, ExceptionTable); > + > + return Result; > +} > + > + > +void JITDwarfEmitter::EmitFrameMoves(intptr_t BaseLabelPtr, > + const std::vector<MachineMove> > &Moves) { > + unsigned PointerSize = TD->getPointerSize(); > + int stackGrowth = stackGrowthDirection == > TargetFrameInfo::StackGrowsUp ? > + PointerSize : -PointerSize; > + bool IsLocal = BaseLabelPtr; > + > + for (unsigned i = 0, N = Moves.size(); i < N; ++i) { > + const MachineMove &am...

Dear all, Here's a new patch with Evan's comments (thx Evan!) and some cleanups. Now the (duplicated) exception handling code is in a new file: lib/ExecutionEngine/JIT/JITDwarfEmitter. This patch should work on linux/x86 and linux/ppc (tested). Nicolas -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: jit-exceptions.patch URL:

...t; void *getPointerToGlobal(GlobalValue *GV, void *Reference, > bool NoNeedStub); > }; > } > > +void DwarfJITEmitter::EmitFrameMoves(intptr_t BaseLabelPtr, > + const > std::vector<MachineMove> &Moves) { > + unsigned PointerSize = TD.getPointerSize(); > + int stackGrowth = > + TM.getFrameInfo()->getStackGrowthDirection() == > + TargetFrameInfo::StackGrowsUp ? > + PointerSize : -PointerSize; > + // TODO bool IsLocal = BaseLabel && strcmp(BaseLabel, "label") > =...

Hi everyone, Here's a patch that enables exception handling when jitting. I've copy/pasted _many_code from lib/Codegen/DwarfWriter.cpp, so we may need to factorize it, but the functionality is there and I'm very happy with it :) lli should now be able to execute the output from llvm-gcc when using exceptions (the UnwindInst instruction is not involved in this patch). Just add the

Emil: I'm using LLVM 1.9 now. When I tried to do what you did I got the following though: $ llvm-g++ -emit-llvm -c x.cpp $ llvm-link -o=linked.o x.o std/*.o sup/*.o WARNING: Linking two modules of different target triples! WARNING: Linking two modules of different target triples! WARNING: Linking two modules of different target triples! ... $ lli linked.o lli((anonymous

...6d7f9] > lli(llvm::MachineFunctionPass::runOnFunction(llvm::Function&)+0x29)[0x811af59] > Segmentation fault > > > What could be the problem? I don't know. =/ All my bytecode files are built for: target datalayout = "e-p:32:32" target endian = little target pointersize = 32 target triple = "i386-portbld-freebsd7.0" Build a small bytecode file on your end, disassemble it, and compare. (llvm-dis < yourfile.o | head -5) LLVMers, given the same endianness and pointersize, can one mix and match LLVM bytecode files produced on different platforms? --Em...

...s incomplete element type this kind of code was accepted by previous versions of gcc as a fragile extension, but is no longer at least in 4.0.1 . is this known? should I file a bug? regards. PS: This code produces such a pattern through llvm-as, and llc -march=c: target endian = little target pointersize = 32 target triple = "i686-apple-darwin8.7.1" %fixarray_array3 = type [3 x %structtype_s] %structtype_s = type { int } int %witness(%fixarray_array3* %p) { %q = getelementptr %fixarray_array3* %p, uint 0, uint 0, uint 0 %v = load int* %q ret int %v }

...and -S options. I can get the human readable IR but I still cannot run it using lli. The output of the IR looks like this. Can some of the information tell me about why the program is not running. ; ModuleID = 'Hel.c' target datalayout = "e-p:32:32" target endian = little target pointersize = 32 target triple = "i686-pc-linux-gnu" %str = internal constant [10 x sbyte] c"Hey there\00" ; <[10 x sbyte]*> [#uses=1] implementation ; Functions: int %main() { entry: %retval = alloca int, align 4 ; <int*> [#uses=2] %tmp =...

...is is a bug. The following code should return the value 17 (I tested with GCC, to be sure): int main() { int i; for (i=0; i<10; i++) if (i>5) i+=10; return i; } But the demo wants to return 7 instead: Output from LLVM disassembler target endian = little target pointersize = 32 deplibs = [ "c", "crtend" ] implementation ; Functions: int %main() { loopexit: call void %__main( ) ret int 7 } declare void %__main() -- Joachim.

...eate a language which can compile itself, therefore I feel I need to understand the Assembler/Byte code format. Starting with a C hello world program there are statements at the beginning of the disassembled bc file that I couldn't find any documentation: target endian = little target pointersize = 32 target triple = "i686-pc-linux-gnu" deplibs = [ "c", "crtend" ] implementation These are "self-explantory" but what are the possible values and what other items should I be prepared to output. Thanks, Wink Saville

...is difficult for most of you to make use of it. The current llvm-gcc builds do not support the -m64 (or -arch x86_64) option so there is no easy way to compile for X86-64. If you really want to try it out, you can manually replace the following lines in the llvm bytecode files from target pointersize = 32 target triple = "i686-apple-darwin8" to target pointersize = 64 target triple = "x86_64-apple-darwin8" Substitute appropriate strings for Linux, etc. Pass the modified the bytecode file to llc and it should generate 64- bit assembly. Alternatively, use the -mtriple= op...

On Tue, 21 Nov 2006, Emil Mikulic wrote: > LLVMers, given the same endianness and pointersize, can one mix and > match LLVM bytecode files produced on different platforms? No, not in general. For example, on the mac, printf it often #defined to printf$ldbl, which doesn't exist on linux. System headers generally foil the ability to move stuff around like that. -Chris -- http:/...

...g.misc. Given :- int ltst(int x) { int i, j; j=0; for(i=0; i<x; i++)j++; return(j); } This is from the online LLVM compiler. AND It does not seem to optimize it down ! ; ModuleID = '/tmp/webcompile/_24843_0.bc' target datalayout = "e-p:32:32" target endian = little target pointersize = 32 target triple = "i686-pc-linux-gnu" implementation ; Functions: int %ltst(int %x) { entry: %x = cast int %x to uint ; <uint> [#uses=1] %tmp13 = setgt int %x, 0 ; <bool> [#uses=1] br bool %tmp13, label %bb, label %bb7 bb:...

Anton Korobeynikov schrieb: > Hello, Philipp. > >> unsigned is 16 bit on my target platform. > Could you please show LLVM bytecode? > I've attached the .bc file and the .c source and output files. I compiled dusing llvm-gcc (not configured as cross-compiler though, so that might be the problem). Nevertheless I don't really see why portable source shouldn't be

...ses=1] %sizeI = ptrtoint i32** %size to i32 ; <i32> [#uses=1] %tmp7 = ashr i32 %tmp6, %sizeI ; <i32> [#uses=1] ret i32 %tmp7 } There, pointer size independent. The problem you see is you are using a frontend targeting a specific platform, so pointersize is known (see the target datalayout line). Andrew

...ccepted by previous versions of gcc as a fragile > extension, > but is no longer at least in 4.0.1 . > > is this known? should I file a bug? > > regards. > > PS: This code produces such a pattern through llvm-as, and llc -march=c: > > target endian = little > target pointersize = 32 > target triple = "i686-apple-darwin8.7.1" > > %fixarray_array3 = type [3 x %structtype_s] > %structtype_s = type { int } > > int %witness(%fixarray_array3* %p) { > %q = getelementptr %fixarray_array3* %p, uint 0, uint 0, uint 0 > %v = load int* %q &...

Hi, I want to ask for a small help for creating an instruction that calls e member method of an object. I suppose that this is not a headache but I am impatient in learning :) I would be very thankful if you can show me an example snippet code that does this in LLVM. Below is described my case. Let's say I have a class TestClass class TestClass { int testMethod(int a); } and I want to

The -c option tells llvm-gcc to build a bytecode file without linking in the LLVM runtime library. This is similar to the -c option for regular gcc, which you use to build multiple separate .o files that you're going to link into a single executable. If you want to build from a single source file, it's easiest just to compile without the -c option. If you're building from

...registers should be enough. Yes. I have done almost all of that already a while ago and it solves almost all problems, as you say. But the problem is a code like: float f; float float_addition(float a, float b) { return a+b; } which is translated by LLVM into: target endian = little target pointersize = 32 target triple = "i686-pc-linux-gnu" deplibs = [ "c", "crtend" ] %f = weak global float 0.000000e+00 ; <float*> [#uses=0] implementation ; Functions: float %float_addition(float %a, float %b) { entry: %tmp.2 = add float %a, %b ; <float> [#uses=1]...