On Thu, Oct 13, 2011 at 10:21 AM, Paolo Bonzini <bonz...@gnu.org> wrote: > 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). >
Why do we do it for MEM then? -- H.J.
