[PATCH][0/n] Merge from match-and-simplify

[Sebastian Pop]

Richard Biener wrote:
> On Thu, 16 Oct 2014, Sebastian Pop wrote:
> 
> > Richard Biener wrote:
> > > 
> > > I have posted 5 patches as part of a larger series to merge
> > > (parts) from the match-and-simplify branch.  While I think
> > > there was overall consensus that the idea behind the project
> > > is sound there are technical questions left for how the
> > > thing should look in the end.  I've raised them in 3/n
> > > which is the only patch of the series that contains any
> > > patterns sofar.
> > > 
> > > To re-iterate here (as I expect most people will only look
> > > at [0/n] patches ;)), the question is whether we are fine
> > > with making fold-const (thus fold_{unary,binary,ternary})
> > > not handle some cases it handles currently.
> > 
> > I have tested on aarch64 all the code in the match-and-simplify against trunk as
> > of the last merge at r216315:
> > 
> > 2014-10-16  Richard Biener  <rguenther@suse.de>
> > 
> >         Merge from trunk r216235 through r216315.
> > 
> > Overall, I see a lot of perf regressions (about 2/3 of the tests) than
> > improvements (1/3 of the tests).  I will try to reduce tests.
> 
> Note that the branch goes much further in exercising the machinery
> than I want to merge at this point (that applies mostly to all
> passes using the SSA propagator such as CCP and VRP and passes
> exercising value-numbering - FRE and PRE).

I see.  Should I run benchmarks only with the patches that you submitted for
trunk?

> I don't understand AARCH64 assembly very well but the above looks like
> RTL issues and/or IVOPTs issues?

I should have posted the first diff between the compilers with -fdump-tree-all:
that would expose the problem at its root.

I have seen that there is a way to dump the folded expressions from the new
functionality, is there a flag to print the folded expressions in current trunk?
It would be interesting to have the same kind of output, such that we could run
a diff between.

Thanks,
Sebastian