[Bug target/29560] [avr] Poor optimization for byte shifts

["Rudolf dot Leitgeb at gmx dot at" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #5 from Rudolf dot Leitgeb at gmx dot at  2010-02-18 13:28 -------
Right away: I am NOT an expert in compiler or optimizer design, so please bear
with me.

I understand, that (((unsigned char)1) << ((unsigned char)something)) may need
more than 8 bits for representation and that gcc's default int size on the
ATmega platform is 16 bits. But the result is assigned to an 8 bit value. I
take it that there is no way to back propagate this potential optimization from
the assignment to the shifting step. If you look in my assembly code, r25 is
computed with great effort yet never transferred anywhere.

The trick with &7 is nice but introduces another unnecessary AND operation. And
it is only correct if the input numebr is guaranteed to be between 0 and 7. Am
I correct that this whole optimization issue comes from the fact that ATmega is
an 8 bit architecture yet gcc's int on that platform is 16 bit?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29560