[Bug tree-optimization/65964] [meta] Operand Shortening

[gjl at gcc dot gnu.org]

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