Re: Match-and-simplify and COND_EXPR

[Richard Biener <rguenther at suse dot de>]

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)))
> 
> 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.

There are probably still corner-cases where the GENERIC exprs we
embed into GIMPLE operands are not handled correctly or optimally.
We jump through multiple hoops to get that right already but I'm sure
I missed some ;)  COND_EXPRs are difficult because the embedded
comparison is simplified separately but how the result needs to be
represented depends on the context.  So more example patterns
certainly help here.

Feel free to open a bugreport.

Btw, I usually "test" this by inspecting the generated code for
a single pattern in a test.pd file and

./build/genmatch --gimple test.pd

Thanks,
Richard.

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