Anatoly Sokolov schreef:
Hi,
Bug #11259 [avr] gcc Double 'andi' missed optimization:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11259
Bug #29560 Poor optimization for character shifts on Atmel AVR:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29560
Bug #29560 seems to be a little different. The bug report is on shifting
with a variable shift count. And the loop for doing this shift is non
optimal (high byte shift because of int promotion or something alike).
While my example works with fixed shifts. Actually, it's bit extraction
implemented as shifting.
My concern is that when rewriting/inverting my logic I get much better
(optimal in most cases) results. So it seems the compiler has not chosen
the most optimal path. It seems like he has two ways of doing the
shifting? Mabye it's some hidden 8-bit/16-bit variable difference?
Testcase:
<snip>
There are two 'and' insn (#24 and #12), but them are not optimized yet. Why?
Probably reason, 'lshiftrt' insn is splited in 'rotate' and 'and' insns in
'pass_split_after_reload' pass of the compiler, but optimization passes
(combine and cse) of which two 'and' insns can merge are run earlier.
I see, to bad...
It is possible to add peephole for merge two 'and' insns. But I do not think
that this decision optimum.
Why not? I agree it's not solving the roots of the problem but it helps
anyway. I am a total noob on GCC internals so this might be a stupid
question...
Thanks for all the explantions! Really interresting stuff.
Greetings,
Wouter
_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list