Bug 65964 - [meta-bug] Operand Shortening
Summary: [meta-bug] Operand Shortening
Status: UNCONFIRMED
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: unknown
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: meta-bug, missed-optimization
Depends on: 14617 14753 30128 60145 65084 14844 17935 39726 41076 45397 65958
Blocks:
  Show dependency tree / graph
 
Reported: 2015-05-01 13:55 UTC by Jeffrey A. Law
Modified: 2021-09-06 10:54 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:

Attachments
combo.c: C test case (469 bytes, text/plain)
2015-05-01 15:32 UTC, Georg-Johann Lay 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Jeffrey A. Law 2015-05-01 13:55:31 UTC 
Meta bug for tracking operand shortening issues
Comment 1 Georg-Johann Lay 2015-05-01 15:32:39 UTC 
Created attachment 35437 [details]
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).