matic at nimp.co.uk
2013-Feb-02 23:50 UTC
[LLVMdev] logic function optimization: IAR 1 - LLVM 0 ?
I gave the following function to IAR compiler (targeting CortexM0) and to clang/LLVM 3.2 (clang -O3 -target thumbv6-eabi -emit-llvm) int calleeSave8(int in[]){ int out=0; int i; for(i=0;i<8;i++){ out ^in[i] & in[(i+1)%8]; }//expand to out (in[0]&in[1])^(in[1]&in[2])^(in[2]&in[3])^(in[3]&in[4])^(in[4]&in[5])^(in[5]&in[6])^(in[6]&in[7])^(in[7]&in[0]) return out; } In such case, IAR compiler is able to factor out half of the and operations so it performs 4 and + 7 xor, LLVM factored only one and operation so it performs 7 and + 7 xor. (I looked at IR code and assembly output) Did I miss some option that would improve the result ? My understanding is that this kind of optimization should be done by the target independent part of the code generator, backends should not have to implement such optimization right ? Cheers, Sebastien -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130202/50eed9cc/attachment.html>
Bill Wendling
2013-Feb-04 22:46 UTC
[LLVMdev] logic function optimization: IAR 1 - LLVM 0 ?
Have you tried armv7? -bw On Feb 2, 2013, at 3:50 PM, matic at nimp.co.uk wrote:> I gave the following function to IAR compiler (targeting CortexM0) and to clang/LLVM 3.2 (clang -O3 -target thumbv6-eabi -emit-llvm) > > int calleeSave8(int in[]){ > int out=0; > int i; > for(i=0;i<8;i++){ > out ^= in[i] & in[(i+1)%8]; > }//expand to out = (in[0]&in[1])^(in[1]&in[2])^(in[2]&in[3])^(in[3]&in[4])^(in[4]&in[5])^(in[5]&in[6])^(in[6]&in[7])^(in[7]&in[0]) > return out; > } > > In such case, IAR compiler is able to factor out half of the and operations so it performs 4 and + 7 xor, LLVM factored only one and operation so it performs 7 and + 7 xor. (I looked at IR code and assembly output) > > Did I miss some option that would improve the result ? > > My understanding is that this kind of optimization should be done by the target independent part of the code generator, backends should not have to implement such optimization right ? > > Cheers, > > Sebastien > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
matic at nimp.co.uk
2013-Feb-05 20:32 UTC
[LLVMdev] logic function optimization: IAR 1 - LLVM 0 ?
Hi, clang -O3 -target thumbv7-eabi -emit-llvm ... llc ... -debug -O3 -code-model=small -march=thumb -mcpu=cortex-m3 ... Does generate slightly better code, but it still computes 7 xor + 7 and. Anyway this should be a target independent optimization isn't it ?? Cheers Sebastien On 2013-02-04 16:46, Bill Wendling wrote:> Have you triedarmv7?> > -bw > > On Feb 2, 2013, at 3:50 PM,matic at nimp.co.ukwrote:> >> I gave the following function to IARcompiler (targeting CortexM0) and to clang/LLVM 3.2 (clang -O3 -target thumbv6-eabi -emit-llvm) int calleeSave8(int in[]){ int out=0; int i; for(i=0;i<8;i++){ out ^= in[i] & in[(i+1)%8]; }//expand to out (in[0]&in[1])^(in[1]&in[2])^(in[2]&in[3])^(in[3]&in[4])^(in[4]&in[5])^(in[5]&in[6])^(in[6]&in[7])^(in[7]&in[0]) return out; } In such case, IAR compiler is able to factor out half of the and operations so it performs 4 and + 7 xor, LLVM factored only one and operation so it performs 7 and + 7 xor. (I looked at IR code and assembly output) Did I miss some option that would improve the result ? My understanding is that this kind of optimization should be done by the target independent part of the code generator, backends should not have to implement such optimization right ? Cheers, Sebastien> >>_______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu [1] http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev [2] Links: ------ [1] http://llvm.cs.uiuc.edu [2] http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130205/cbe504ea/attachment.html>