search for: x86codeemitter

...e the jit is tailjmping to the wrong function address. the following change would reenable tailcallopt in jit. But i am pretty sure that this is not the correct fix (since i don't really understand what is going on :). maybe evan can comment on this? regards arnold Index: lib/Target/X86/X86CodeEmitter.cpp =================================================================== --- lib/Target/X86/X86CodeEmitter.cpp (revision 45541) +++ lib/Target/X86/X86CodeEmitter.cpp (working copy) @@ -601,7 +601,8 @@ if (MO.isMachineBasicBlock()) { emitPCRelativeBlockAddress(MO.getMBB());...

Hi, The attached patch contains the following changes: * X86InstrInfo.cpp: Synchronize a few places with the code in X86CodeEmitter.cpp * X86CodeEmitter.cpp: Avoid the longer SIB encoding on amd64 if it is not neeed. Zoltan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090501/fe30fbd0/attachment.html> -------------- next par...

...eng-2 wrote: > > Looks good. Thanks. > > Evan > > On May 1, 2009, at 8:40 AM, Zoltan Varga wrote: > >> Hi, >> >> The attached patch contains the following changes: >> >> * X86InstrInfo.cpp: Synchronize a few places with the code in >> X86CodeEmitter.cpp >> * X86CodeEmitter.cpp: Avoid the longer SIB encoding on amd64 if it >> is not neeed. >> >> Zoltan >> <llvm.diff>_______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://ll...

...gLexer.l", line 191: warning, -s option given but default rule can be matched gmake[2]: Leaving directory `/usr/home/wanderer/pkg/build/llvm/obj/tools/llvmc' 2) gcc 3.5 (mainline CVS) Mostly result using ~0 (signed int) expression as value of unsigned int function parameter. Compiling X86CodeEmitter.cpp /home/wanderer/pkg/build/llvm/src/llvm/lib/Target/X86/X86CodeEmitter.cpp: In member function `void<unnamed>::Emitter::emitMemModRMByte(const llvm::MachineInstr&, unsigned int, unsigned int)': /home/wanderer/pkg/build/llvm/src/llvm/lib/Target/X86/X86CodeEmitter.cpp:437: warning:...

...mple > object format, as the ELF code is totally broken and outdated. Lets > use the following as the basis for our discussion? I've never looked at the MachO code as I do not have such a platform nor do I know the file format. Could we concentrate on the ELF backend, please. > 3. X86CodeEmitter > - a MachineFunctionPass, NOT a MachineCodeEmitter (Could the naming > change perhaps?) Yes, it uses a MachineCodeEmitter in its internals (MCE) and as a constructor argument. > This class receives (during construction) a reference to a > MachineCodeEmitter (e.g. MachOCodeEmitter,...

...;unnamed>::LoopExtractor]' /home/wanderer/pkg/build/llvm/src/llvm/lib/Transforms/IPO/LoopExtractor.cpp:50: instantiated from here /home/wanderer/pkg/build/llvm/src/llvm/include/llvm/PassSupport.h:171: warning: converting of negative value `-0x000000001' to `unsigned int' Compiling X86CodeEmitter.cpp /home/wanderer/pkg/build/llvm/src/llvm/lib/Target/X86/X86CodeEmitter.cpp: In member function `void<unnamed>::Emitter::emitMemModRMByte(const llvm::MachineInstr&, unsigned int, unsigned int)': /home/wanderer/pkg/build/llvm/src/llvm/lib/Target/X86/X86CodeEmitter.cpp:437: warning:...

...LFCodeEmitter don't even use the BufferBegin/BufferEnd/CurBufferPtr system exposed by the base MachineCodeEmitter. There is a big "FIXME" and an abort at the beginning of the ELFCodeEmitter::startFunction. This is why I used MachO to 'grok' the concept. > > >> 3. X86CodeEmitter >>   - a MachineFunctionPass, NOT a MachineCodeEmitter (Could the naming >> change perhaps?) > > Yes, it uses a MachineCodeEmitter in its internals (MCE) and as a > constructor argument. > > runOnMachineFunction is a standard LLVM message we cannot play around with > i...

Looks good. Thanks. Evan On May 1, 2009, at 8:40 AM, Zoltan Varga wrote: > Hi, > > The attached patch contains the following changes: > > * X86InstrInfo.cpp: Synchronize a few places with the code in > X86CodeEmitter.cpp > * X86CodeEmitter.cpp: Avoid the longer SIB encoding on amd64 if it > is not neeed. > > Zoltan > <llvm.diff>_______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://l...

...anks. >> >> Evan >> >> On May 1, 2009, at 8:40 AM, Zoltan Varga wrote: >> >>> Hi, >>> >>> The attached patch contains the following changes: >>> >>> * X86InstrInfo.cpp: Synchronize a few places with the code in >>> X86CodeEmitter.cpp >>> * X86CodeEmitter.cpp: Avoid the longer SIB encoding on amd64 if it >>> is not neeed. >>> >>> Zoltan >>> <llvm.diff>_______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.u...

...t;> >>> On May 1, 2009, at 8:40 AM, Zoltan Varga wrote: >>> >>>> Hi, >>>> >>>> The attached patch contains the following changes: >>>> >>>> * X86InstrInfo.cpp: Synchronize a few places with the code in >>>> X86CodeEmitter.cpp >>>> * X86CodeEmitter.cpp: Avoid the longer SIB encoding on amd64 if it >>>> is not neeed. >>>> >>>> Zoltan >>>> <llvm.diff>_______________________________________________ >>>> LLVM Developers mailing list >&...

...able to get past the error by calling InitializeNativeTargetAsmParser() in my code. Now I have a failure in resolving external libraries, so looking into that (recompiled with --enable-ffi but I now get an error LLVMgold.so not found). Then I hda to disable the following code in lib/Target/X86/X86CodeEmitter.cpp: > case TargetOpcode::INLINEASM: > // We allow inline assembler nodes with empty bodies - they can > // implicitly define registers, which is ok for JIT. > //if (MI.getOperand(0).getSymbolName()[0]) > // report_fatal_error("in X86CodeEm...

...ast the error by calling InitializeNativeTargetAsmParser() in my code. Now I have a failure in resolving external libraries, so looking into that (recompiled with --enable-ffi but I now get an error LLVMgold.so not found). >> >> Then I hda to disable the following code in lib/Target/X86/X86CodeEmitter.cpp: >>> case TargetOpcode::INLINEASM: >>> // We allow inline assembler nodes with empty bodies - they can >>> // implicitly define registers, which is ok for JIT. >>> //if (MI.getOperand(0).getSymbolName()[0]) >>> /...

...bals list, and all relocations to the parent section's relocation list; adds a symbol for the function to the MachOWriter's SymbolTable. [In general, all the operations in finishFunction actually modify the data of the MachOWriter. Shouldn't these be pushed into the MachOWriter? ] 3. X86CodeEmitter - a MachineFunctionPass, NOT a MachineCodeEmitter (Could the naming change perhaps?) This class receives (during construction) a reference to a MachineCodeEmitter (e.g. MachOCodeEmitter, which in turn stores a reference to a MachOWritter). The runOnMachineFunction for the X86CodeEmitter does:...

...ugh - even > the fast allocator is pretty slow. I haven't seen what your plan > is for register allocation or were you planning on just using a few > registers in defined ways? My first idea was to implement a linear scan allocator integrated into the code generation pass. > Also, X86CodeEmitter.cpp is going away to be replaced with the MC > emitters. Yes, I remember reading about this on the mailing list. With our simulator generators we are still living in 2.2/2.6 land, though, but we will change that. X86CodeEmitter was only meant to indicate that in my intended fast path there is...

...er, which is responsible for actually emitting > bytes into a buffer for a function. Should it have methods for > emitting instructions/operands, or should it only work at the byte, > dword, etc. level? It works at primatine byte, word, dword level only. the *CodeEmitter classes like the X86CodeEmitter class are responsible for generating machine code and use the MachineCodeEmitter class to do this. > ObjectCodeEmitter, is responsible for emission of object 'files' into > a memory buffer. This includes handling of all object headers, > management of sections/segments, symbol a...

...o get past the error by calling InitializeNativeTargetAsmParser() in my code. Now I have a failure in resolving external libraries, so looking into that (recompiled with --enable-ffi but I now get an error LLVMgold.so not found). > > Then I hda to disable the following code in lib/Target/X86/X86CodeEmitter.cpp: >> case TargetOpcode::INLINEASM: >> // We allow inline assembler nodes with empty bodies - they can >> // implicitly define registers, which is ok for JIT. >> //if (MI.getOperand(0).getSymbolName()[0]) >> // report_fatal_error(&qu...

Paolo Invernizzi wrote: > There was a similar problem some time ago, and was resolved with alloca. > I think it's a better solution to use the stack instead of the heap... I tend to agree, but the constructors won't get called if it's an object array -- anyway, this particular case there was no objects, just pointers and bools so alloca should be fine. I'll leave it to

hi, when using the execution engine (no matter, if JIT or Interpreter) i get the following assertion as soon as i use boost::shared_ptr: /build/buildd/llvm-2.5/lib/Target/X86/X86CodeEmitter.cpp:522: void<unnamed>::Emitter::emitInstruction(const llvm::MachineInstr&, const llvm::TargetInstrDesc*): Assertion `0 && "JIT does not support inline asm!\n"' failed. how can i find out which instruction is executed at this point or in which function we are cu...

...39; > /home/wanderer/pkg/build/llvm/src/llvm/lib/Transforms/IPO/LoopExtractor.cpp:50: > instantiated from here > /home/wanderer/pkg/build/llvm/src/llvm/include/llvm/PassSupport.h:171: > warning: converting of negative value `-0x000000001' to `unsigned int' > > Compiling X86CodeEmitter.cpp > /home/wanderer/pkg/build/llvm/src/llvm/lib/Target/X86/X86CodeEmitter.cpp: In > member function `void<unnamed>::Emitter::emitMemModRMByte(const > llvm::MachineInstr&, unsigned int, unsigned int)': > /home/wanderer/pkg/build/llvm/src/llvm/lib/Target/X86/X86CodeEmitte...

Where do DEBUG and EH label values originate from ? Where's their allocator ? I am looking at some code in X86CodeEmitter.cpp line 574, where a labels value is extraced from an operand. But dont know where to look in the frontend or middle end to find the LabelID allocator. If some kind person could point me in the right direction. Many thanks in advance, Aaron -------------- next part -------------- An HTML attac...