[LLVMdev] GSoC 2011: Fast JIT Code Generation for x86-64
jan_sjodin at yahoo.com
Tue Apr 5 10:39:25 PDT 2011
----- Original Message ----
> From: Jim Grosbach <grosbach at apple.com>
> To: Viktor Pavlu <vpavlu at gmail.com>
> Cc: llvmdev at cs.uiuc.edu
> Sent: Tue, April 5, 2011 1:16:34 PM
> Subject: Re: [LLVMdev] GSoC 2011: Fast JIT Code Generation for x86-64
> 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>
> >> 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 what fastisel was created for - there are just IR
> >> constructs that don't go through that path. The idea is that fastisel
> >> will get most of the IR and everything that'd be really hard we just
> >> punt to the DAG. I imagine running more things through fastisel would
> >> help.
> > 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 register
>allocator as well.
> What Eric is suggesting is instead locating which IR constructs are not being
>handled by fast-isel and are causing problems (i.e., are being frequently
>encountered in your code-base) and implementing fast-isel handling for them.
>That will remove the selectiondag overhead that you've identified as the
>primary compile-time problem.
An alternative that would expand LLVMs capabilities would be to write an
interpreter for the LLVM IR itself. A well written interpretation framework
could be used by the compiler as well.
More information about the llvm-dev