This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix PR56478


On Fri, Mar 8, 2013 at 1:30 PM, Jakub Jelinek <jakub@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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]