This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]