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 <rguent...@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
