https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65964
Georg-Johann Lay <gjl at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gjl at gcc dot gnu.org --- Comment #1 from Georg-Johann Lay <gjl at gcc dot gnu.org> --- Created attachment 35437 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35437&action=edit combo.c: C test case The problem in PR41076 is mostly about composing bytes to wider integer values as indicated in the test case. It can be handled in the backend (in the case of avr) by adding some more complex combiner patterns, at least for the 16-bit cases like for (from .combine dump): (set (regi:HI 24) (ior:HI (ashift:HI (reg:HI 51) (const_int 8)) (zero_extend:HI (reg:QI 24)))) or (set (reg:HI 24) (ior:HI (ashift:HI (zero_extend:HI (reg:QI 49)) (const_int 8)) (zero_extend:HI (reg:QI 24)))) The 32-bit cases are beyond anything a sane avr backend could do. Maybe such patterns could be detected similar to the bswap detection? (which does not work very well from my experience).