https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71785
--- Comment #20 from Aleksey ---
(In reply to Segher Boessenkool from comment #19)
> '-freorder-blocks'
> Reorder basic blocks in the compiled function in order to reduce
> number of taken branches and improve code locality.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71785
--- Comment #19 from Segher Boessenkool ---
(In reply to Aleksey from comment #16)
> > > It would be helpful if you give the explanation how these options affect
> > > "un-factoring".
> >
> > What options? -fno-reorder-blocks? Those doo the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71785
--- Comment #18 from Aleksey ---
(In reply to Andrew Pinski from comment #17)
> First off internal documentation is not user documentation.
> Second internal documentation is not always in sync with the code. In this
> case it seems like it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71785
--- Comment #17 from Andrew Pinski ---
First off internal documentation is not user documentation.
Second internal documentation is not always in sync with the code. In this
case it seems like it is not fully. Basically BB reordering does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71785
--- Comment #16 from Aleksey ---
> > It would be helpful if you give the explanation how these options affect
> > "un-factoring".
>
> What options? -fno-reorder-blocks? Those doo the same to this code as
> they do anywhere else: the compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71785
--- Comment #15 from Segher Boessenkool ---
(In reply to Aleksey from comment #14)
> Performance is not the case here, so don't bother with it. Strict order of
> labels and using everywhere "jmp reg" instead of "jmp rel + jmp reg" - this
> is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71785
--- Comment #14 from Aleksey ---
(In reply to Segher Boessenkool from comment #13)
> (In reply to Aleksey from comment #12)
> > But adding these two flags "-fno-reorder-blocks-and-partition
> > -fno-reorder-blocks"
>
> If you say that basic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71785
--- Comment #13 from Segher Boessenkool ---
(In reply to Aleksey from comment #12)
> But adding these two flags "-fno-reorder-blocks-and-partition
> -fno-reorder-blocks"
If you say that basic blocks should not be reordered, then they
are not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71785
Aleksey changed:
What|Removed |Added
CC||rndfax at yandex dot ru
--- Comment #12 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71785
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71785
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71785
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |ASSIGNED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71785
--- Comment #8 from Segher Boessenkool ---
Author: segher
Date: Mon Nov 21 15:15:21 2016
New Revision: 242665
URL: https://gcc.gnu.org/viewcvs?rev=242665=gcc=rev
Log:
Testcase for PR71785
gcc/testsuite/
PR rtl-optimization/71785
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71785
--- Comment #7 from Segher Boessenkool ---
Author: segher
Date: Fri Nov 18 09:14:52 2016
New Revision: 242584
URL: https://gcc.gnu.org/viewcvs?rev=242584=gcc=rev
Log:
bb-reorder: Improve compgotos pass (PR71785)
For code like the testcase in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71785
--- Comment #6 from Andres Freund ---
Hi,
Can confirm this patch fixes the specific code generation issue I
complained about, leading to an overall 1.9% improvement in TPC-H
performance. There's still some counterproductive jumps, but they're
15 matches
Mail list logo
