llvm dev - Jul 2013 - [LLVMdev] LLVM 3.3 JIT code speed

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?

Thanks.

Stéphane Letz

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

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