similar to: [LLVMdev] Bug in x86 JIT fast emitter.

Evan, Any plans to add it any time soon? It would be really appreciated. Evan Cheng wrote: > X86 JIT does not yet support TLS. > > Evan > On Jun 12, 2009, at 2:48 AM, Mark Shannon wrote: > >> Hi there, >> >> I think I've found a bug in the x86 JIT. I get an assertion failure >> when >> using thread-local variables and the fast emitter.

X86 JIT does not yet support TLS. Evan On Jun 12, 2009, at 2:48 AM, Mark Shannon wrote: > Hi there, > > I think I've found a bug in the x86 JIT. I get an assertion failure > when > using thread-local variables and the fast emitter. > It only happens with the JIT, the fast emiiter and thread-locals. > (The IR passes the verifier) > > Here's the failure: >

No plans. I recommend you hack on it. :-) Sorry, all features are done on demand. Evan On Jun 12, 2009, at 1:08 PM, Mark Shannon wrote: > Evan, > > Any plans to add it any time soon? > It would be really appreciated. > > Evan Cheng wrote: >> X86 JIT does not yet support TLS. >> >> Evan >> On Jun 12, 2009, at 2:48 AM, Mark Shannon wrote: >>

Hi Mark, Can't we run "lli -fast" on your .bc file instead of llc? Nicolas Mark Shannon wrote: > Hi there, > > I think I've found a bug in the x86 JIT. I get an assertion failure when > using thread-local variables and the fast emitter. > It only happens with the JIT, the fast emiiter and thread-locals. > (The IR passes the verifier) > > Here's the

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.

Stefan Weigert wrote: > 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 &&

hi, thanks for your quick replies. -DBOOST_SP_USE_PTHREADS worked indeed. however, i didn't measure the performance but i would assume that the boost developers had a good reason for using assembler in this context. will llvm ever support inline assembly? is there anybody who is working on that? thanks, stefan. On Tuesday 21 July 2009 01:54:20 pm Vladimir Prus wrote: > Stefan Weigert

> Aaron, I mailed in the same mail twice (by mistake), you answered both > copies. Differently! > > In any case, I've re-read what exists. I'm dumping what I understand > here, so that we can discuss in detail. I'm using MachO as the example > object format, as the ELF code is totally broken and outdated. Lets > use the following as the basis for our discussion?

Hi Everyone, When I compile a program with clang with debug symbols enabled and I try to run it using the JIT (lli) I get the following error message. I am running on Lion (10.7.4). Thanks. George >> pseudo instructions should be removed before code emission UNREACHABLE executed at /Users/JD/Software/llvm3.1/llvm-3.1.src/lib/Target/X86/X86CodeEmitter.cpp:736! 0 lli

> 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. I don't mind using the ELF backend as our test case, it just seems that the ELFWriter/ELFCodeEmitter don't even use the BufferBegin/BufferEnd/CurBufferPtr system exposed by the base MachineCodeEmitter. There is a big

OK, here's a new patch that adds the infrastructure and the implementation for X86, ARM and PPC of GetInstSize and GetFunctionSize. Both functions are virtual functions defined in TargetInstrInfo.h. For X86, I moved some commodity functions from X86CodeEmitter to X86InstrInfo. What do you think? Nicolas Evan Cheng wrote: > > I think both of these belong to TargetInstrInfo. And

On Mon, Apr 4, 2011 at 9:50 PM, Eric Christopher <echristo at apple.com> wrote: > > On Apr 1, 2011, at 6:53 AM, Viktor Pavlu wrote: > >> [...] Although most optimizations are turned off >> already and the FastISel instruction selector is used, the "fast" path >> for first-time code generation is still the bottleneck [...] > > This is effectively

>> Sorry, I disagree actually the MachineCodeEmitter or the >> 'MachineCodeWritter' does not do any file handling at all. Do look at the >> code for the MachineCodeWritter and you will see it only writes to memory >> and if it reaches the end of the allotted memory I believe higher ordered >> logic reallocates a larget buffer and starts again from scratch.

Can someone explain what MCInst is vs. MachineIntr? I'm porting some patches we have here that affect MachineInstrs and am wondering whether I need to make similar changes in MCInst. Why do we have two machine instruction representations? -Dave

Hi, I have a problem with creating a MFENCE on X86 with SSE In X86InstrSSE.td, a MFENCE is def MFENCE : I<0xAE, MRM6m, (outs), (ins), "mfence", [(int_x86_sse2_mfence)]>, TB, Requires< [HasSSE2]>; In X86CodeEmitter.cpp in emitInstruction case X86II::MRM6m: case X86II::MRM7m: { intptr_t PCAdj = (CurOp+4 != NumOps) ?

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:

> Currently, the MachO and ELF Writers and MachineCodeEmitters are > hard-coded into LLVMTargetMachine and llc. I am also interested in working on this area and interested in writting a COFF file backend. > In other words, the 'object file generation' capabilities of the > Common Code Generator are not generic. I was looking at making a parallel class to MachineCodeEmitter,

Aaron, I mailed in the same mail twice (by mistake), you answered both copies. Differently! In any case, I've re-read what exists. I'm dumping what I understand here, so that we can discuss in detail. I'm using MachO as the example object format, as the ELF code is totally broken and outdated. Lets use the following as the basis for our discussion? There are 3 classes which

On Apr 1, 2011, at 6:53 AM, Viktor Pavlu wrote: > I currently work on generating fast cycle-accurate simulators[2]. For > this, our institute has implemented a two-part adaptive compilation > scheme using the LLVM-JIT. Although most optimizations are turned off > already and the FastISel instruction selector is used, the "fast" path > for first-time code generation is

Hi All, I'd like to propose a fast path through code generation for x86-84 in the JIT execution engine as part of 2011's Google Summer of Code program. While the LLVM-JIT is very popular as a first try at jitting programming languages, projects have abandoned the LLVM-JIT when disappointed with the overall runtime. The problem is, that the benefit of faster execution is traded for longer