[LLVMdev] General strategy to optimize LLVM IR
Stéphane Letz
letz at grame.fr
Wed Jul 17 07:07:35 PDT 2013
Le 16 juil. 2013 à 20:07, David Blaikie <dblaikie at gmail.com> a écrit :
> On Tue, Jul 16, 2013 at 8:16 AM, Stéphane Letz <letz at grame.fr> wrote:
>> Hi,
>>
>> Our DSL emit sub-optimal LLVM IR that we optimize later on (LLVM IR ==> LLVM IR) before dynamically compiling it with the JIT. We would like to simply follow what clang/clang++ does when compiling with -O1/-O2/-O3 options. Our strategy up to now what to look at the opt.cpp code and take part of it in order to implement our optimization code.
>>
>> It appears to be rather difficult to follow evolution of the LLVM IR optimization strategies. With LLVM 3.3 our optimization code does not produce code as fast as the one produced with clang -03 anymore. Moreover the new vectorizations passes are still not working.
>>
>> It there a recommended way to add -O1/-O2/-O3 kind of optimizations on LLVM IR code? Any code to look at beside the opt.cpp tool?
>
> I'm not /entirely/ sure what you're asking. It sounds like you're
> asking "what passes should my compiler's -O1/2/3 flag's correspond to"
> and one answer to that is to look at Clang (I think Clang's is
> different from opt/llc's, maybe).
>
After taking code from LLVM 3.3 opt.cpp tool, the LLVM IR optimizations now produce correctly optimized code (by comparing with what clang -O3 -emit-llvm and opt -O3 give).
Then the LLVM IR is given to JIT, but now we see speedup regression compared to what we had with LLVM 3.1 (by comparing how clang -O3 does with a C version of our generated code and what is compiled using a LLVM IR ==> (optimizations passes) ==> LLVM IR ==> JIT.
Our code basically does:
EngineBuilder builder(fResult->fModule);
builder.setOptLevel(CodeGenOpt::Aggressive);
builder.setEngineKind(EngineKind::JIT);
builder.setUseMCJIT(true);
(I tried to add builder.setMCPU(llvm::sys::getHostCPUName()); without changes…)
Is there any new things to "activate" in LLVM 3.3 to get similar speed results to what we had with LLVM 3.1?
Thanks
Stéphane Letz
More information about the llvm-dev
mailing list