Re: [PATCH][3/n] Merge from match-and-simplify, first patterns and questions

[Richard Biener <rguenther at suse dot de>]

On Fri, 17 Oct 2014, Jakub Jelinek wrote:

> On Wed, Oct 15, 2014 at 01:40:49PM +0200, Richard Biener wrote:
> > 
> > This adds a bunch of simplifications with constant operands
> > or ones that simplify to constants, such as a + 0, x * 1.
> > 
> > It's a patch mainly to get a few questions answered for further
> > pattern merges:
> > 
> >  - The branch uses multiple .pd files and includes them from
> >    match.pd trying to group related stuff together.  It has
> >    become somewhat difficult to do that grouping in some
> >    sensible manner so I am not sure this is the best approach.
> >    Any opinion?  We can simply put everything into match.pd
> >    and group visually by overall comments.
> 
> That would be probably my preference, unless match.pd grows too big.

Ok.

> >  - Each pattern I will add will either be already implemented
> >    in some form in fold-const.c or tree-ssa-forwprop.c.  Once
> >    the machinery is exercised from fold-const.c and
> >    tree-ssa-forwprop.c I can remove the duplicates at the
> >    same time I add a pattern.  Should I do that?
> 
> I guess it depends, if the new pattern covers the old one well, sure,
> the STRIP_{,SIGN_}NOPS issues might be more important, TREE_SIDE_EFFECTS
> probably less important (those shouldn't be really constant expressions
> and thus there should be fewer users expecting stuff to be folded).
> 
> In any cases, we need to be prepared to cure some folding
> regressions if people report them and we find them desirable to be
> restored.  Hopefully there won't be hundreds of such reports.

Agreed.  So any STRIP_NOPS that is not a STRIP_SIGN_NOPS (thus
a sing-changing conversion strip) would be a missed optimization
on GIMPLE which we should address anyhow.  For STRIP_SING_NOPS,
yes - if we find uses that matter we can address them or delay
the simplification to GIMPLE where the conversion should vanish
as useless.

Note that we can address the issues by amending patterns with
conditional conversions (with appropriate predicate on the
allowed types of course).  Note that the patterns would need to
as  take care of putting back required conversions that
are stripped off similar to how fold-const.c wraps almost all
operands in a fold_convert (...).

In theory one could try removing all STRIP_NOPS calls from fold-const.c
and look for fallout.

I'll keep an eye on it.

Thanks,
Richard.