http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50603
Uros Bizjak <ubizjak at gmail dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- Target| |x32 Status|UNCONFIRMED |RESOLVED URL| |http://gcc.gnu.org/ml/gcc-p | |atches/2011-10/msg00547.htm | |l Resolution| |FIXED Target Milestone|--- |4.7.0 --- Comment #8 from Uros Bizjak <ubizjak at gmail dot com> 2011-10-09 09:30:09 UTC --- (In reply to comment #6) > It doesn't work since we fail to decompose subreg. The question here is, why combine creates: Failed to match this instruction: (set (mem:SI (and:DI (plus:DI (subreg:DI (mult:SI (reg/v:SI 85 [ i ]) (const_int 4 [0x4])) 0) (subreg:DI (reg:SI 106) 0)) (const_int 4294967292 [0xfffffffc])) [0 MEM[symbol: x, index: D.2741_1, step: 4, offset: 4294967292B]+0 S4 A32]) (reg/v:SI 85 [ i ])) Considering that this is in fact zero-extension, the "optimized" pattern is worse than sticking subreg to the whole address, i.e. (and:DI (subreg:DI (plus:SI (mult:SI (reg/v:SI 85 [ i ]) (const_int 4 [0x4])) (reg:SI 106)) 0) (const_int 4294967295 [0xffffffff])) Please note that we have registers in two different modes in the former pattern. The later pattern would be recognized by i386.c code. Anyway, the original problem is solved, instead of hijacking exisiting PR, please open a new PR (IMO, RTL optimization).