similar to: [LLVMdev] GSoC 2011: Fast JIT Code Generation for x86-64

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

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

On Apr 5, 2011, at 2:56 AM, Viktor Pavlu wrote: > 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

Thanks for all the replies! I wanted to closely resemble what the CACAO VM[1] backend did with success for a long time: for every CACAO IR instruction, there is a sequence of x86 instructions that get written directly to the executable memory. In CACAO, registers are used while available, then everything is spilled. Relocations are resolved and patched in a second go. It seems this is similar to

Jim Grosbach <grosbach at apple.com> writes: >> To me, increasing coverage of the FastISel seemed more involved than >> directly emitting opcodes to memory, with a lesser outlook on >> reducing overhead. > > That seems extremely unlikely. You'd be effectively re-implementing > both fast-isel and the MC binary emitter layers, and it sounds like a > new

Hi Viktor, On Tue, Apr 5, 2011 at 9:41 PM, Óscar Fuentes <ofv at wanadoo.es> wrote: > Jim Grosbach <grosbach at apple.com> writes: > > >> To me, increasing coverage of the FastISel seemed more involved than > >> directly emitting opcodes to memory, with a lesser outlook on > >> reducing overhead. > > > > That seems extremely unlikely.

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

On Sun, May 3, 2009 at 3:41 PM, Aaron Gray <aaronngray.lists at googlemail.com> wrote: > 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 >

> > The other thing that might work, is having TargetMachine remember how > > the fast-isel option got set, and make OptLevelChanger do the right > > thing. But that seems like a hack to work around Mips not obeying the > > specified optimization level, honestly. > > I think we should do that as well. I don't think it's right that optnone > enables Fast

The driving goal of 'optnone' is to have an easy way for programmers to get an "-O0 like" debugging experience for selected functions, without making them build everything with –O0. To that end, we turn off as much optimization as we reasonably can, but in the context of a pipeline that is generally expecting optimizations to be enabled, in practice we can't exactly match –O0

Dear Forum, I have been wracking my head over this problem for the past few days. I have a dataset of (x,y). I have been able to obtain a nonlinear regression line using nls. However, we would like to do some statistical analysis. I would like to obtain a confidence interval for the curve. We thought we could divide up the curve into piecewise linear regressions and compute CIs from those

Well, 'optnone' is already not identical to -O0, and given the nature of things, probably can't be; but I am persuaded that it's reasonable for it to honor the -fast-isel option as a debugging tactic. I'll take an AI to make this happen. Thanks, --paulr P.S. One nit, the "O0 + optnone" case should not have an asterisk, the FastISel flag is not manipulated if the opt

It seems that fast-isel for intel does not handle strlen. It's a general problem in fast-isel . ~/llvmw/build/Deb~/llvmw/build/Debug+Asserts/bin/clang -O0 -mllvm -fast-isel-verbose -mllvm -fast-isel strlen1.c strlen1.c:12:3: warning: implicitly declaring library function 'printf' with type 'int (const char *, ...)' printf("%i\n", len); ^

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: X86CodeEmitter.cpp:516: void<unnamed>::Emitter::emitInstruction(const llvm::MachineInstr&, const llvm::TargetInstrDesc*):

> > I was mucking around in FastISel, and was surprised to see the test > > llvm/test/CodeGen/Mips/emergency-spill-slot-near-fp.ll > > failed. This was surprising because it specifies -fast-isel=false. > > > > Does the Mips code generator use fast-isel even when you ask it not to? > > Thanks, > > --paulr > > This seems to be an all-targets bug.

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.

I was mucking around in FastISel, and was surprised to see the test llvm/test/CodeGen/Mips/emergency-spill-slot-near-fp.ll failed. This was surprising because it specifies -fast-isel=false. Does the Mips code generator use fast-isel even when you ask it not to? Thanks, --paulr

Curious. I removed -fno-experimental-isel and all of the tests *except* control_tool.c passed. I would have expected all of them to pass if blockaddress works. I'll try to look at some asm and see what's going on. -David Jonas Hahnfeld <hahnjo at hahnjo.de> writes: > Hi David, > > I was the one who originally added the flag to fix failures

What is the purpose of tablegen created files for fast-isel? If I make the following change to Makefile in lib/Target/Mips BUILT_SOURCES = MipsGenRegisterInfo.inc MipsGenInstrInfo.inc \ MipsGenAsmWriter.inc MipsGenCodeEmitter.inc \ MipsGenDAGISel.inc MipsGenCallingConv.inc \ - MipsGenSubtargetInfo.inc MipsGenMCCodeEmitter.inc \ +

We're seeing OMPT tests fail on AArch64: libomp :: ompt/misc/control_tool.c libomp :: ompt/synchronization/master.c libomp :: ompt/synchronization/taskwait.c The failure mode is similar for all of them: openmp/runtime/test/ompt/misc/control_tool.c:26:17: error: CHECK-NEXT: expected string not found in input // CHECK-NEXT: {{^}}[[MASTER_ID]]: