Match-and-simplify and COND_EXPR

[Richard Biener]

On Wed, 5 Nov 2014, Andrew Pinski wrote:

> Hi,
>   I was trying to hook up tree-ssa-phiopt to match-and-simplify using
> either gimple_build (or rather using gimple_simplify depending on if
> we want to produce cond_expr for conditional move).  I ran into a
> problem.
> With the pattern below:
> /* a ? 0 : 1 -> a if 0 and 1 are integral types. */
> (simplify
>   (cond_expr @0 integer_zerop integer_onep)
>   (if (INTEGRAL_TYPE_P (type))
>     (convert @0)))

Ok, so you are capturing a GENERIC expr here but nothing knows that.
It would work if you'd do (ugh)

(for op (lt le eq ne ge gt)
 (simplify
  (cond_expr (op @0 @1) integer_zerop integer_onep)
  (if (INTEGRAL_TYPE_P (type))
   (convert (op @0 @1)))))
(simplify
 (cond_expr SSA_NAME@0 integer_zerop integer_onep)
  (if (INTEGRAL_TYPE_P (type))
   (convert @0))))

as a workaround.  To make your version work will require (quite)
some special-casing in the code generator or maybe the resimplify
helper.  Let me see if I can cook up a "simple" fix.

Richard.

> This produces a gimple statement with an incorrect gimple statement
> where we have have a convert with an compare expression.
> 
> t.c: In function ‘f’:
> t.c:1:5: error: invalid operand in unary operation
>  int f(int c, int a, int b)
>      ^
> _4 = (int) (c_2(D) != 0);
> 
> 
> Did I implement the pattern incorrectly or is there a bug due to the
> way cond_expr handles its 0th operand in that it is valid for compares
> there in gimple form.
> 
> I don't have a good patch to test tree-ssa-phiopt.c connection due the
> patch having extra code in it already which handles creating cond_expr
> for conditional moves already.
> 
> Thanks,
> Andrew Pinski
> 
> 

-- 
Richard Biener <rguenther@suse.de>
SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer, HRB 21284
(AG Nuernberg)
Maxfeldstrasse 5, 90409 Nuernberg, Germany