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

Reply via email to