This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/65964] [meta] Operand Shortening
- From: "gjl at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Fri, 01 May 2015 15:32:39 +0000
- Subject: [Bug tree-optimization/65964] [meta] Operand Shortening
- Auto-submitted: auto-generated
- References: <bug-65964-4 at http dot gcc dot gnu dot org/bugzilla/>
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).