On Fri, 31 Jul 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.
>
> Thanks.
>
> The ! syntax seems fine. If we run out, we can always introduce an
> attribute-like syntax: (plus[force_leaf] @1 @2), but we aren't there yet. And
> either this feature will see a lot of use and deserve its short syntax, or it
> won't and it will be easy to reclaim '!' for something else.
>
> I am wondering about GENERIC. IIUC, '!' is ignored for GENERIC. Should we
> protect some/most uses of this syntax with #if GIMPLE? In my case, I think
> resimplify might simply return non-0 because it swapped the operands, which
> should not be sufficient to enable the transformation.
I think the resimplify logic also only works on GIMPLE. But you are
right - I forgot about GENERIC. But it should be straight-forward
to adjust its code generation from
{
tree _o1[2], _r1;
_o1[0] = captures[2];
_o1[1] = unshare_expr (captures[4]);
_r1 = fold_build2_loc (loc, PLUS_EXPR, TREE_TYPE (_o1[0]),
_o1[0], _o1[1]);
res_op1 = _r1;
}
tree res_op2;
{
tree _o1[2], _r1;
_o1[0] = captures[3];
_o1[1] = captures[4];
_r1 = fold_build2_loc (loc, PLUS_EXPR, TREE_TYPE (_o1[0]),
_o1[0], _o1[1]);
res_op2 = _r1;
}
tree _r;
_r = fold_build3_loc (loc, VEC_COND_EXPR, type, res_op0,
res_op1, res_op2);
to add a
if (!CONSTANT_CLASS_P (_r1) || DECL_P (_r1))
return NULL_TREE;
or maybe if (EXPR_P (_r1))? On GENRIC it's a bit more difficult
since (plus! @0 @1) should be OK for say @0 == a + b and @1 == 0
simplifying to @0 itself. Likewise @0 == a + 1 and @1 == 1
simplifying to a + 2 should be OK (we've changed a leaf). Or
maybe that's not OK - who knows...
Of course we'd better change fold_build.. to fold_binary as well.
Or we simply automatically disable those patterns for GENERIC
(though that would probably be unexpected).
Sorry for not thinking about GENERIC - seems like a (small) mess
there ;)
Richard.
