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.
