Hello,
for me as GCC developer, this is definitely an intersting observation. Let
me briefly explain what happen here.
-fguess-branch-probability does a lot more than just BB reordering. The way
GCC works is that it first guesses probability of every branch and then uses
the probabilities to
* Markus Trippelsdorf wrote:
> On 2015.04.12 at 07:47 +0200, Ingo Molnar wrote:
> >
> > * Linus Torvalds wrote:
> >
> > > On Sat, Apr 11, 2015 at 11:57 AM, Thomas Gleixner
> > > wrote:
> > > >
> > > > I thinks its just the no-guess one:
> > > >
> > > >textdata dec patch
* Thomas Gleixner wrote:
> > How much of that 5% comes from code alignment? Or was this on
> > *top* of the 1-byte alignment testt?
>
> I thinks its just the no-guess one:
>
>text data dec patch reduction
>
> 7563475 1781048 10302987
>
>
On Sun, 2015-04-12 at 07:47 +0200, Ingo Molnar wrote:
> * Linus Torvalds wrote:
>
> > On Sat, Apr 11, 2015 at 11:57 AM, Thomas Gleixner <
> > t...@linutronix.de> wrote:
> > >
> > > I thinks its just the no-guess one:
> > >
> > >textdata dec patch reduction
> > >
* Linus Torvalds wrote:
> On Sat, Apr 11, 2015 at 11:57 AM, Thomas Gleixner wrote:
> >
> > I thinks its just the no-guess one:
> >
> >textdata dec patch reduction
> > 7563475 1781048 10302987
> > 7192973 1780024 9931461 no-guess-4.8%
> >
On 2015.04.12 at 07:47 +0200, Ingo Molnar wrote:
>
> * Linus Torvalds wrote:
>
> > On Sat, Apr 11, 2015 at 11:57 AM, Thomas Gleixner
> > wrote:
> > >
> > > I thinks its just the no-guess one:
> > >
> > >textdata dec patch reduction
> > > 7563475 1781048
Hello,
for me as GCC developer, this is definitely an intersting observation. Let
me briefly explain what happen here.
-fguess-branch-probability does a lot more than just BB reordering. The way
GCC works is that it first guesses probability of every branch and then uses
the probabilities to
* Linus Torvalds torva...@linux-foundation.org wrote:
On Sat, Apr 11, 2015 at 11:57 AM, Thomas Gleixner t...@linutronix.de wrote:
I thinks its just the no-guess one:
textdata dec patch reduction
7563475 1781048 10302987
7192973 1780024 9931461
On 2015.04.12 at 07:47 +0200, Ingo Molnar wrote:
* Linus Torvalds torva...@linux-foundation.org wrote:
On Sat, Apr 11, 2015 at 11:57 AM, Thomas Gleixner t...@linutronix.de
wrote:
I thinks its just the no-guess one:
textdata dec patch reduction
On Sun, 2015-04-12 at 07:47 +0200, Ingo Molnar wrote:
* Linus Torvalds torva...@linux-foundation.org wrote:
On Sat, Apr 11, 2015 at 11:57 AM, Thomas Gleixner
t...@linutronix.de wrote:
I thinks its just the no-guess one:
textdata dec patch reduction
* Thomas Gleixner t...@linutronix.de wrote:
How much of that 5% comes from code alignment? Or was this on
*top* of the 1-byte alignment testt?
I thinks its just the no-guess one:
text data dec patch reduction
7563475 1781048 10302987
* Markus Trippelsdorf mar...@trippelsdorf.de wrote:
On 2015.04.12 at 07:47 +0200, Ingo Molnar wrote:
* Linus Torvalds torva...@linux-foundation.org wrote:
On Sat, Apr 11, 2015 at 11:57 AM, Thomas Gleixner t...@linutronix.de
wrote:
I thinks its just the no-guess one:
* Linus Torvalds wrote:
> On Sat, Apr 11, 2015 at 11:57 AM, Thomas Gleixner wrote:
> >
> > I thinks its just the no-guess one:
> >
> >textdata dec patch reduction
> > 7563475 1781048 10302987
> > 7192973 1780024 9931461 no-guess-4.8%
> >
On Sat, Apr 11, 2015 at 11:57 AM, Thomas Gleixner wrote:
>
> I thinks its just the no-guess one:
>
>textdata dec patch reduction
> 7563475 1781048 10302987
> 7192973 1780024 9931461 no-guess-4.8%
> 7354819 1781048958464 align-1
On Sat, 11 Apr 2015, Linus Torvalds wrote:
> On Apr 11, 2015 2:20 AM, "Ingo Molnar" wrote:
> >
> > Another thing caught my attention (and I'm hijacking the RCU thread
> > again): GCC's notion of how to place branches seems somewhat random,
> > and rather bloaty.
> >
> > So I tried the experiment
On Apr 11, 2015 2:20 AM, "Ingo Molnar" wrote:
>
> Another thing caught my attention (and I'm hijacking the RCU thread
> again): GCC's notion of how to place branches seems somewhat random,
> and rather bloaty.
>
> So I tried the experiment below on an x86 defconfig, turning off GCC's
> branch
Apr 2015 11:16:30 +0200
Subject: [PATCH] x86: Turn off GCC branch probability heuristics
Not-Signed-off-by: Ingo Molnar
---
arch/x86/Makefile | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 5ba2d9ce82dc..7c12b3f56915 100644
--- a/arch/x86/Makefile
On Sat, Apr 11, 2015 at 11:57 AM, Thomas Gleixner t...@linutronix.de wrote:
I thinks its just the no-guess one:
textdata dec patch reduction
7563475 1781048 10302987
7192973 1780024 9931461 no-guess-4.8%
7354819 1781048958464
On Sat, 11 Apr 2015, Linus Torvalds wrote:
On Apr 11, 2015 2:20 AM, Ingo Molnar mi...@kernel.org wrote:
Another thing caught my attention (and I'm hijacking the RCU thread
again): GCC's notion of how to place branches seems somewhat random,
and rather bloaty.
So I tried the experiment
Apr 2015 11:16:30 +0200
Subject: [PATCH] x86: Turn off GCC branch probability heuristics
Not-Signed-off-by: Ingo Molnar mi...@kernel.org
---
arch/x86/Makefile | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 5ba2d9ce82dc..7c12b3f56915 100644
On Apr 11, 2015 2:20 AM, Ingo Molnar mi...@kernel.org wrote:
Another thing caught my attention (and I'm hijacking the RCU thread
again): GCC's notion of how to place branches seems somewhat random,
and rather bloaty.
So I tried the experiment below on an x86 defconfig, turning off GCC's
* Linus Torvalds torva...@linux-foundation.org wrote:
On Sat, Apr 11, 2015 at 11:57 AM, Thomas Gleixner t...@linutronix.de wrote:
I thinks its just the no-guess one:
textdata dec patch reduction
7563475 1781048 10302987
7192973 1780024 9931461
22 matches
Mail list logo
