On October 17, 2014 6:35:58 PM CEST, Sebastian Pop <seb...@gmail.com> wrote:
>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?
Yes. What I posted sofar should be a no-op performance wise.
Benchmarks on the branch are still useful though as eventually all changes
should get merged to trunk if enough patterns are implemented.
Richard.
>> 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
