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

[Jim Grosbach]

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

>> That won't help the slow register allocation problem though - 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 nothing in between the LLVM-IR passes and the final
> emission of the code, i.e. an LLVM-IR pass that produces x86-64.
> 
> - Viktor
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev