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

[Jan Sjodin]

----- 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> 
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 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.
> 
> -Jim

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.

- Jan