------- 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
