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

[Richard Biener]

On Wed, 5 Aug 2020, Richard Biener wrote:

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

OK, so the if (!..) route would be quite awkward with how the
code generator is structured.  Using EH would be straight-forward,
just wrap the code generation part in

 try {
...
 } catch (...) { return false }

and replace return false/NULL_TREE with throw; but of course we
have EH disabled.  Then the above might reasonably well translate
to a goto to a unique label we'd have to invent.

I'm testing a patch with the goto.

Richard.