Re: [RFC] Meta-description for tree and gimple folding

[Richard Biener <rguenther at suse dot de>]

On Tue, 4 Mar 2014, Marc Glisse wrote:

> On Mon, 3 Mar 2014, Richard Biener wrote:
> 
> > > How do I restrict some subexpression to have
> > > a single use?
> > 
> > This kind of restrictions come via the valueize() hook - simply
> > valueize to NULL_TREE to make the match fail (for example
> > SSA_NAME_OCCURS_IN_ABNORMAL_PHI could be made fail that way).
> 
> Shouldn't that single-use property depend more on the transformation and less
> on where it is called from? a+b-b -> a is always going to be a good idea
> (well, register pressure aside), even if a+b is used in many other places. But
> if you are using a*b elsewhere, turning a*b+c into FMA doesn't make so much
> sense.

Yeah, that's true.

> Well, we can always call has_single_use on some @i if it is an SSA_NAME.

Sure.  As I have to add the capability to guard patterns with flags
doing an additional has_single_use test there is easy (but of course
that's something only available when in SSA form - something to keep
in mind if we also want to create a GENERIC variant of the transform).

Note that the concept of having a single-use makes whether a pattern
matches possibly dependent on the order of processing uses and
dependent on dead code being removed.  Just sth to keep in mind if you
want the maximum number of transforms rather than being cautious
by default.

> > > If I write a COND_EXPR matcher, could it generate code for phiopt as
> > > well?
> > 
> > Not sure, what do you have in mind specifically?
> 
> fold-const.c has the equivalent of:
> (define_match_and_simplify abs
>   (COND_EXPR (LT_EXPR @0 zero_p) (NEGATE_EXPR @0) @0)
>   (ABS_EXPR @0))
> 
> (it would help to be able to write LT_EXPR|LE_EXPR, maybe even to try
> automatically simplify(!a)?c:b for a?b:c)
> which works well on trees, but requires more complicated code in phiopt (same
> for min/max).

Yeah, inventing short-cuts for stuff like LT_EXPR|LE_EXPR or
(PLUS_EXPR sub-expr1 sub-expr2) vs. (PLUS_EXPR sub-expr2 sub-expr1)
is on my list.  In the end it will (internally) duplicate the
pattern to have one for each variant.

I'm still pondering over the exact syntax for both (I can easily
add builtin knowledge for commutative operators of course).  Eventually
the preprocessor comes to our rescue here ...

#define X(CMP) \
  (define_match_and_simplify \
    ((COND_EXPR (CMP @0 zero_p) (NEGATE_EXPR @0) @0) \
    (ABS_EXPR @0))
X(LT_EXPR)
X(LE_EXPR)

uglier than sth like

(define_op LT_OR_LE_EXPR LT_EXPR|LE_EXPR)
(define_match_and_simplify
  ((COND_EXPR (LT_OR_LE_EXPR @0 zero_p) ...

or what you proposed.  But how do you handle

 (BIT_IOR_EXPR (LT_EXPR|LE_EXPR @0 @1) (GE_EXPR|GT_EXPR @0 @1))

for example?  a) Match variants in lock-step?  b) Have the above
generate 4 variants?  c) Disallow it (looks error-prone)?

I'd rather keep it simple for now ;)

> > > How do you handle a
> > > transformation that currently tries to recursively fold something else and
> > > does the main transformation only if that simplified?
> > 
> > And doesn't do the other folding (because it's not in the IL literally?)?
> > Similar to the cst without overflow case, by writing custom C code
> > and allowing that to signal failure.
> 
> I am not sure if it will be easy to write code that works for generic and
> gimple. I'll see...

That's true - though GIMPLE and GENERIC share trees which makes it
easy enough for most of the cases.  We'll see ...

For now I'm concentrating of fitting the framework into forwprop,
replacing manual patterns that occur there.

Richard.