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?
Jakub
