avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] Inversion of logic improves size speed


From: Wouter van Gulik
Subject: Re: [avr-gcc-list] Inversion of logic improves size speed
Date: Tue, 07 Aug 2007 10:48:50 +0200
User-agent: Thunderbird 2.0.0.6 (Windows/20070728)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]