On Fri, Mar 8, 2013 at 1:30 PM, Jakub Jelinek <ja...@redhat.com> wrote:
> On Fri, Mar 08, 2013 at 01:16:37PM +0100, Marek Polacek wrote:
>> --- gcc/predict.c.mp 2013-03-07 20:01:01.078417558 +0100
>> +++ gcc/predict.c 2013-03-08 11:35:05.227603993 +0100
>> @@ -1028,13 +1028,13 @@ static bool
>> is_comparison_with_loop_invariant_p (gimple stmt, struct loop *loop,
>> tree *loop_invariant,
>> enum tree_code *compare_code,
>> - int *loop_step,
>> + tree *loop_step,
>> tree *loop_iv_base)
>> {
>> tree op0, op1, bound, base;
>> affine_iv iv0, iv1;
>> enum tree_code code;
>> - int step;
>> + tree step;
>>
>> code = gimple_cond_code (stmt);
>> *loop_invariant = NULL;
>> @@ -1077,7 +1077,7 @@ is_comparison_with_loop_invariant_p (gim
>> bound = iv0.base;
>> base = iv1.base;
>> if (host_integerp (iv1.step, 0))
>> - step = tree_low_cst (iv1.step, 0);
>> + step = iv1.step;
>> else
>> return false;
>> }
>> @@ -1086,7 +1086,7 @@ is_comparison_with_loop_invariant_p (gim
>> bound = iv1.base;
>> base = iv0.base;
>> if (host_integerp (iv0.step, 0))
>> - step = tree_low_cst (iv0.step, 0);
>> + step = iv0.step;
>> else
>> return false;
>> }
>
> If the callers use double_int computation, perhaps there is
> no reason for the host_integerp checks and all we could verify is
> that the trees have TREE_CODE (iv0.step) etc. == INTEGER_CST
> (and perhaps that if the type of them is unsigned, then they don't
> have the msb set (i.e.
> !TYPE_UNSIGNED (TREE_TYPE (iv0.step))
> || !tree_to_double_int (iv0.step).is_negative () ).
> But perhaps that can be left for 4.9 as an improvement?
>
>> @@ -1224,34 +1224,78 @@ predict_iv_comparison (struct loop *loop
>> && host_integerp (compare_base, 0))
>
> Ditto the host_integerp checks above.
>
>> + if ((compare_step.scmp (double_int_zero) == 1)
>
> I believe compare_step should be known not to be zero here (there are
> integer_zerop checks earlier, aren't they), so this could be also
> !compare_step.is_negative ()
> ?
>
> Other than that it looks good to me, Richard, is this fine for you too?
Yes.
Thanks,
Richard.
> Jakub
