This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][0/n] Merge from match-and-simplify
- From: Richard Biener <rguenther at suse dot de>
- To: Sebastian Pop <sebpop at gmail dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Fri, 17 Oct 2014 19:34:49 +0200
- Subject: Re: [PATCH][0/n] Merge from match-and-simplify
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot LSU dot 2 dot 11 dot 1410151450430 dot 20733 at zhemvz dot fhfr dot qr> <20141016203852 dot GB29134 at f1 dot c dot bardezibar dot internal> <alpine dot LSU dot 2 dot 11 dot 1410170951450 dot 9891 at zhemvz dot fhfr dot qr> <20141017163558 dot GD29134 at f1 dot c dot bardezibar dot internal>
On October 17, 2014 6:35:58 PM CEST, Sebastian Pop <sebpop@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 <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?
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