On Thu, Oct 13, 2011 at 19:19, H.J. Lu <hjl.to...@gmail.com> wrote: > On Thu, Oct 13, 2011 at 10:01 AM, Paolo Bonzini <bonz...@gnu.org> wrote: >> On 10/13/2011 06:35 PM, Richard Kenner wrote: >>>> >>>> It never calls make_extraction. There are several cases handled >>>> for AND operation. But >>>> >>>> (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])) >>>> >>>> isn't one of them. >>> >>> Yes, clearly. Otherwise it would work! The correct fix for this problem >>> is to make it to do that. That's where this needs to be fixed: in >>> make_compound_operation. >> >> An and:DI is cheaper than a zero_extend:DI of an and:SI. So GCC is correct >> in not doing this transformation. I think adding a case to >> make_compound_operation that simply undoes the transformation (without >> calling make_extraction) is fine if you guard it with if (in_code == MEM). >> > > We first expand zero_extend:DI address to and:DI and then try > to restore zero_extend:DI. Why do we do this transformation > to begin with?
Because outside of a MEM it may be beneficial _not_ to restore zero_extend:DI in this case (depending on rtx_costs). Paolo
