Bug 65964

Summary: [meta-bug] Operand Shortening
Product: gcc Reporter: Jeffrey A. Law <law>
Component: tree-optimizationAssignee: Not yet assigned to anyone <unassigned>
Status: UNCONFIRMED ---    
Severity: enhancement CC: gjl
Priority: P3 Keywords: meta-bug, missed-optimization
Version: unknown   
Target Milestone: ---   
Host: Target:
Build: Known to work:
Known to fail: Last reconfirmed:
Bug Depends on: 14617, 14753, 17935, 30128, 60145, 65084, 14844, 39726, 41076, 45397, 65958    
Bug Blocks:    
Attachments: combo.c: C test case

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