Re: extend fwprop optimization

[Wei Mi <wmi at google dot com>]

Hi,

This is the fwprop extension patch which is put in order. Regression
test and bootstrap pass. Please help to review its rationality. The
following is a brief description what I have done in the patch.

In order to make fwprop more effective in rtl optimization, we extend
it to handle general expressions instead of the three cases listed in
the head comment in fwprop.c. The major changes include a) We need to
check propagation correctness for src exprs of def which contain mem
references. Previous fwprop for the three cases above doesn't have the
problem. b) We need a better cost model because the benefit is usually
not so apparent as the three cases above.

For a general fwprop problem, there are two possible sources where
benefit comes from. The frist is the new use insn after propagation
and simplification may have lower cost than itself before propagation,
or propagation may create a new insn, that could be splitted or
peephole optimized later and get a lower cost. The second is that if
all the uses are replaced with the src of the def insn, the def insn
could be deleted.

So instead of check each def-use pair independently, we use DU chain
to track all the uses for a def. For each def-use pair, we attempt the
propagation, record the change candidate in changes[] array, but we
wait to confirm the changes until all the pairs with the same def are
iterated. The changes confirmation is done in the func
confirm_change_group_by_cost. We only do this for fwprop. For
fwprop_addr, the benefit of each change is ensured by
propagation_rtx_1 using should_replace_address, so we just confirm all
the changes without checking benefit again.

Thanks,
Wei.

On Wed, Feb 27, 2013 at 1:56 PM, Wei Mi <wmi@google.com> wrote:
> Yes, I agree with you. fold_rtx also needs to be extended because now
> it only handles the case similar as follows for shift insn:
>   a = b op const1
>   c = a >> const2
> for our motivational case, the second operand of the first insn is a
> reg instead of a const. We also need to add the truncation support for
> our case in simplify_binary_operation.
>
> I will send out a more official patch about fwprop extension soon.
> Then it may be easier to talk about its rationality.
>
> Thanks,
> Wei.
>
> On Wed, Feb 27, 2013 at 1:21 PM, Steven Bosscher <stevenb.gcc@gmail.com> wrote:
>> On Wed, Feb 27, 2013 at 7:37 PM, Wei Mi wrote:
>>> What do you think?
>>
>> I think you'll not be able to teach fold_rtx to perform the
>> transformation you want it to do without having SHIFT_COUNT_TRUNCATED
>> set for i386. I already tried it the other day, but GCC won't do the
>> truncation without knowing the insn is really a shift insn and
>> shift_truncation_mask returns something useful.
>>
>> Ciao!
>> Steven
>>
>>
>> Index: cse.c
>> ===================================================================
>> --- cse.c       (revision 196182)
>> +++ cse.c       (working copy)
>> @@ -3179,9 +3179,22 @@ fold_rtx (rtx x, rtx insn)
>>
>>         switch (GET_CODE (folded_arg))
>>           {
>> +         case SUBREG:
>> +           /* If the SUBREG_REG comes in from an AND, and this is not a
>> +              paradoxical subreg, then try to fold the SUBREG.  */
>> +           if (REG_P (SUBREG_REG (folded_arg))
>> +               && ! paradoxical_subreg_p (folded_arg))
>> +             {
>> +               rtx y = lookup_as_function (SUBREG_REG (folded_arg), AND);
>> +               if (y != 0)
>> +                 y = simplify_gen_binary(AND, GET_MODE (folded_arg),
>> +                                         XEXP(y, 0), XEXP(y, 1));
>> +               if (y != 0)
>> +                 folded_arg = y;
>> +             }
>> +           /* ... fall through ...  */
>>           case MEM:
>>           case REG:
>> -         case SUBREG:
>>             const_arg = equiv_constant (folded_arg);
>>             break;

Attachment: ChangeLog
Description: Binary data

Attachment: patch
Description: Binary data