[LLVMdev] LLVM 3.3 JIT code speed

[Kaylor, Andrew]

I understand you to mean that you have isolated the actual execution time as your point of comparison, as opposed to including runtime loading and so on.  Is this correct?

One thing that changed between 3.1 and 3.3 is that MCJIT no longer compiles the module during the engine creation process but instead waits until either a function pointer is requested or finalizeObject is called.  I would guess that you have taken that into account in your measurement technique, but it seemed worth mentioning.

What architecture/OS are you testing?

With LLVM 3.3 you can register a JIT event listener (using ExecutionEngine::RegisterJITEventListener) that MCJIT will call with a copy of the actual object image that gets generated.  You could then write that image to a file as a basis for comparing the generated code.  You can find a reference implementation of the interface in lib/ExecutionEngine/IntelJITEvents/IntelJITEventListener.cpp.

-Andy

-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Stéphane Letz
Sent: Thursday, July 18, 2013 11:20 AM
To: Eli Friedman
Cc: llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] LLVM 3.3 JIT code speed


Le 18 juil. 2013 à 19:07, Eli Friedman <eli.friedman at gmail.com> a écrit :

> On Thu, Jul 18, 2013 at 9:07 AM, Stéphane Letz <letz at grame.fr> wrote:
>> Hi,
>> 
>> Our DSL LLVM IR emitted code (optimized with -O3 kind of IR ==> IR passes) runs slower when executed with the LLVM 3.3 JIT, compared to what we had with LLVM 3.1. What could be the reason?
>> 
>> I tried to play with TargetOptions without any success.
>> 
>> Here is the kind of code we use to allocate the JIT:
>> 
>>    EngineBuilder builder(fResult->fModule);
>>    builder.setOptLevel(CodeGenOpt::Aggressive);
>>    builder.setEngineKind(EngineKind::JIT);
>>    builder.setUseMCJIT(true);
>>    builder.setCodeModel(CodeModel::JITDefault);
>>    builder.setMCPU(llvm::sys::getHostCPUName());
>> 
>>    TargetOptions targetOptions;
>>    targetOptions.NoFramePointerElim = true;
>>    targetOptions.LessPreciseFPMADOption = true;
>>    targetOptions.UnsafeFPMath = true;
>>    targetOptions.NoInfsFPMath = true;
>>    targetOptions.NoNaNsFPMath = true;
>>    targetOptions.GuaranteedTailCallOpt = true;
>> 
>>   builder.setTargetOptions(targetOptions);
>> 
>>    TargetMachine* tm = builder.selectTarget();
>> 
>>    fJIT = builder.create(tm);
>>    if (!fJIT) {
>>        return false;
>>    }
>>    ..
>> 
>> Any idea?
> 
> It's hard to say much without seeing the specific IR and the code 
> generated from that IR.
> 
> -Eli

Our language can do either:

1) DSL  ==> C/C++  ===> clang/gcc ===> exec  code

or

1) DSL  ==> LLVM IR  ===> (optimisation passes) ==>  LLVM  IR  ==> LLVM JIT ==> exex code

1) and 2) where running at same speed with LLVM 3.1, but 2) is now slower with LLVM 3.3 

I compared the LLVM IR that is generated by the 2) chain *after* the optimization passes, with the one that is generated with 1) and clang -emit-llvm -03 with the pure C input. The two are the same. So my conclusion what that the way we are activating the JIT is no more correct in 3.3, or we are missing new steps that have to be done in JIT?

Stéphane Letz


_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev