[Bug tree-optimization/62630] [5 regression] gcc.dg/graphite/vect-pr43423.c FAILs

["mircea.namolaru at inria dot fr" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62630

--- Comment #10 from Mircea Namolaru <mircea.namolaru at inria dot fr> ---
On my Intel x86-64 platform changed in graphite-isl-ast-to-gimple.c:

- static int graphite_expression_type_precision = 128 <= max_mode_int_precision
?
-                          128 : max_mode_int_precision;
+ static int graphite_expression_type_precision = 32;

The computation are done on INT, and you get this code for basic block 4 (and
vectorization performed):

  _28 = MIN_EXPR <n_5(D), mid_6(D)>;
  _29 = _28 > 0;
  if (_29 != 0)
    goto <bb 5>;
  else
    goto <bb 8>;

In my opinion the casts introduced cause problems to scalar evolution (and you
are right,
MIN/MAX are not the problem). 

I will look into two directions, and choose the quickest one fixing the
regression.
1) not to generate casts in Graphite, if correctness is not affected (as in
this case). 
But determining when the use of a longer size signed type is required is not so
simple. 
2) modify handling of casts in scalar evolution. But I am not familiar with
this code.

----- Original Message -----
> From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
> To: "mircea namolaru" <mircea.namolaru@inria.fr>
> Sent: Wednesday, February 18, 2015 12:22:55 PM
> Subject: [Bug tree-optimization/62630] [5 regression] gcc.dg/graphite/vect-pr43423.c FAILs
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62630
> 
> --- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
> (In reply to Mircea Namolaru from comment #7)
> > Graphite generates MAX/MIN expressions.
> > 
> > I've modified Graphite to use the original types of "n" and "mid" in MIN
> > and
> > MAX, and to not generate the casts of "n" and "mid" to a longer signed INT
> > before MIN/MAX, and the vectorization succeeded.
> > 
> > It seems that it is not a Graphite problem but a scalar evolution one.
> > Scalar evolution is not able to handle MIN/MAX expressions in the presence
> > of casts. Beside vectorization also further unrolling is prevented.
> 
> Can you share a patch with that modification?  I'd like to look at the
> differences it makes with respect to SCEV / niter analysis.  Note that
> neither SCEV nor niter analysis handle MIN/MAX_EXPRs explicitely.  It might
> be that
> 
>   <bb 2>:
>   if (n_5(D) > 0)
>     goto <bb 4>;
> ...
>   <bb 4>:
>   _28 = (signed long) n_5(D);
>   _29 = (signed long) mid_6(D);
>   _30 = MIN_EXPR <_28, _29>;
>   _31 = _30 > 0;
>   if (_31 != 0)
> 
> can be simplified to mid_6(D) > 0 by expansion/folding in some way though
> if there are no casts in the way.  Not sure.  I suppose ISL doesn't get to
> know that n > 0 if the loop enters (and doesn't exploit that knowledge)?
> 
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
>