[PATCH] Amend match.pd syntax with force-simplified results

[Richard Biener]

On Tue, 4 Aug 2020, Marc Glisse wrote:

> On Fri, 31 Jul 2020, Richard Biener wrote:
> 
> > This adds a ! marker to result expressions that should simplify
> > (and if not fail the simplification).  This can for example be
> > used like
> >
> > (simplify
> >  (plus (vec_cond:s @0 @1 @2) @3)
> >  (vec_cond @0 (plus! @1 @3) (plus! @2 @3)))
> >
> > to make the simplification only apply in case both plus operations
> > in the result end up simplified to a simple operand.
> 
> (replacing plus with bit_ior)
> The generated code in gimple_simplify_BIT_IOR_EXPR may look like
> 
>   {
>     tree _o1[2], _r1;
>     _o1[0] = captures[2];
>     _o1[1] = captures[4];
>     gimple_match_op tem_op (res_op->cond.any_else (), BIT_IOR_EXPR, TREE_TYPE
>     (_o1[0]), _o1[0], _o1[1]);
>     tem_op.resimplify (lseq, valueize);
>     _r1 = maybe_push_res_to_seq (&tem_op, NULL);
>     if (!_r1) return false;
>     res_op->ops[1] = _r1;
>   }
> 
> In particular, it contains this "return false" which directly exits the
> function, instead of just giving up on this particular transformation and
> trying the next one. I'll reorder my transformations to work around this, but
> it looks like a pre-existing limitation.

Yes, that's a pre-existing limitation/feature.  Once the "match" part of
a pattern applied, (plus (vec_cond:s @0 @1 @2) @3) in this case,
it wins even if it doesn't succeed in the end.  Patterns are "tried"
in the order they appear in match.pd, so you have to make sure to
put more specific ones before generic ones for example

(simplify
 (plus @1 @2)
 (if (false)
  @1)))

would shadow any later pattern with an outermost (plus ...).

genmatch tries to warn about such situations but obviously it can't
always guess correctly, in particular about "late" fails.

Hmm, looks like it doesn't warn about

(simplify
 (plus @1 @2)
 (if (false)
  @1))

(simplify
 (plus (minus @1 @2) @2)
 @1)

ah, it works in this case.  I guess which cases fall thru really
depend on the actual code generation and we could "fix" the above
mentioned issue with, hmm ... EH?  (need some block-structured thing,
placing gotos and labels will be too ugly in the code generator).
Or simply nest things more and turn

 if (..) return false;
 ...
 return true;

into

 if (!...)
   {
     ...
     return true;
   }

I guess it's something we could indeed improve on.

Richard,

-- 
Richard Biener <rguenther@suse.de>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)