Hi Janis,
[EMAIL PROTECTED] (Janis Johnson) wrote on 01.09.05 in <[EMAIL PROTECTED]>:
[quoteto.xps]
> On Thu, Sep 01, 2005 at 11:45:35PM +0200, Steven Bosscher wrote:
> > On Thursday 01 September 2005 23:19, girish vaitheeswaran wrote:
> > > Sorry I still did not follow. This is what I
> > > unde
Hello,
> > >you may try adding -fmove-loop-invariants flag, which enables new
> > >invariant motion pass.
> >
> > That cleaned up both my simplified test case, and the code it
> > originated from. It also cleaned up a few other cases where I
> > was noticing worse performance with FDO enabled.
On Friday 02 September 2005 00:53, Janis Johnson wrote:
> Girish started this thread about problems he is seeing with GCC 3.4.3
> (see http://gcc.gnu.org/ml/gcc/2005-07/msg00866.html). Others of us
> chimed in about similar issues with later versions. Suggestions for
> avoiding the problems have
On Thu, Sep 01, 2005 at 11:45:35PM +0200, Steven Bosscher wrote:
> On Thursday 01 September 2005 23:19, girish vaitheeswaran wrote:
> > Sorry I still did not follow. This is what I
> > understood. During Feedback optimization apart from
> > the -fprofile-generate, one needs to turn on
> > -fmove-lo
On Thursday 01 September 2005 23:19, girish vaitheeswaran wrote:
> Sorry I still did not follow. This is what I
> understood. During Feedback optimization apart from
> the -fprofile-generate, one needs to turn on
> -fmove-loop-invariants.
You don't "need to". It just might help iff you are using
Sorry I still did not follow. This is what I
understood. During Feedback optimization apart from
the -fprofile-generate, one needs to turn on
-fmove-loop-invariants. However this option is not
recognized by the gcc 3.4.4 or 3.4.3 compilers. What
am I missing?
-girish
--- Eric Christopher <[EMAIL
> >you may try adding -fmove-loop-invariants flag, which enables new
> >invariant motion pass.
>
> That cleaned up both my simplified test case, and the code it
> originated from. It also cleaned up a few other cases where I
> was noticing worse performance with FDO enabled. Thanks!!
>
> Perhap
On Aug 31, 2005, at 3:40 PM, girish vaitheeswaran wrote:
I do not see this flag in gcc3.4.4.
Am I missing something?
you may try adding -fmove-loop-invariants flag,
which enables new
invariant motion pass.
The "new invariant motion pass".
-eric
I do not see this flag in gcc3.4.4.
perflab2% gcc -o conftest -O3 -march=pentium4
-fmove-loop-invariants conftest.c
cc1: error: unrecognized command line option
"-fmove-loop-invariants"
Am I missing something?
-girish
--- Zdenek Dvorak <[EMAIL PROTECTED]>
wrote:
> Hello,
>
> > >A more likel
>you may try adding -fmove-loop-invariants flag, which enables new
>invariant motion pass.
That cleaned up both my simplified test case, and the code it
originated from. It also cleaned up a few other cases where I
was noticing worse performance with FDO enabled. Thanks!!
Perhaps this option sh
Hello,
> >A more likely source of performance degradation is that loop unrolling
> >is enabled when profiling, and loop unrolling is almost always a bad
> >pessimization on 32 bits x86 targets.
>
> To clarify, I was compiling with -funroll-loops and -fpeel-loops
> enabled in both cases.
>
> The
> Do you have specific testcase? It would be interesting to see if new
> optimizer can catch up at least on kill-loop branch.
Here is a simplified version of what I observed. In the non-FDO case,
the loop invariant load of the constant 32 is removed from the loop.
When FDO is enabled, the load r
I have tried with gcc 3.4.4 and still see the same
20%slowdown. If you folks are able to crack this, do
let me know. On my earlier attempts I had tried to
disable all of the flags that feedback optimization
turns on (except the ones that are turned on by
default) and still got the 20% slowdown.
Is
>
> There was some discussion a few weeks ago about some apps running slower
> with FDO enabled.
>
> I've recently investigated a similar situation using mainline. In my case,
> the fact that the loop_optimize pass is disabled during FDO was the cause
> of the slowdown. It appears that was rece
>A more likely source of performance degradation is that loop unrolling
>is enabled when profiling, and loop unrolling is almost always a bad
>pessimization on 32 bits x86 targets.
To clarify, I was compiling with -funroll-loops and -fpeel-loops
enabled in both cases.
The FDO slowdown in my case
On Tuesday 30 August 2005 17:53, Peter Steinmetz wrote:
> While this doesn't explain all of the degradations discussed (some were
> showing up on older versions of the compiler), it may explain some.
There is a lot of empirical evidence that the loop optimizer already
doesn't do many useful things
There was some discussion a few weeks ago about some apps running slower
with FDO enabled.
I've recently investigated a similar situation using mainline. In my case,
the fact that the loop_optimize pass is disabled during FDO was the cause
of the slowdown. It appears that was recently disabled
t; > >
> > > Can someone help me out on how to proceed with
> > this.
> > >
> > > Thanks
> > > -girish
> > >
> > >
> > > --- Jan Hubicka <[EMAIL PROTECTED]> wrote:
> > >
> > > > > I starte
> >
> > Thanks
> > -girish
> >
> >
> > --- Jan Hubicka <[EMAIL PROTECTED]> wrote:
> >
> > > > I started with a clean slate in my build
> > > environment
> > > > and did not have any residual files hanging
> > > ar
not have any residual files hanging
> > around.
> > > Are the steps I have indicated in my earlier email
> > > correct. Is there a way I can break down the
> > problem
> > > into a smaller sub-set of flags and eliminate the
> > flag
> > > causing
problem. What I mean is
> since
> > -fprofile-generate and -fprofile-use enable a
> bunch of
> > flags, would it make sense to avoid profiling and
> try
> > out some of the individual flags on a trial and
> error
> > basis. If so what would be the flags to star
; causing the performance problem. What I mean is
> since
> > -fprofile-generate and -fprofile-use enable a
> bunch of
> > flags, would it make sense to avoid profiling and
> try
> > out some of the individual flags on a trial and
> error
> > basis. If so what would be
problem. What I mean is since
-fprofile-generate and -fprofile-use enable a bunch of
flags, would it make sense to avoid profiling and try
out some of the individual flags on a trial and error
basis. If so what would be the flags to start the
trials with.
-girish
Before we go any farther, are
g
> causing the performance problem. What I mean is since
> -fprofile-generate and -fprofile-use enable a bunch of
> flags, would it make sense to avoid profiling and try
> out some of the individual flags on a trial and error
> basis. If so what would be the flags to start the
It would be pr
. What I mean is since
-fprofile-generate and -fprofile-use enable a bunch of
flags, would it make sense to avoid profiling and try
out some of the individual flags on a trial and error
basis. If so what would be the flags to start the
trials with.
-girish
--- Jan Hubicka <[EMAIL PROTECTED]>
> On Wed, Jul 20, 2005 at 10:45:01AM -0700, girish vaitheeswaran wrote:
> > > --- Steven Bosscher <[EMAIL PROTECTED]> wrote:
> > >
> > > > On Wednesday 20 July 2005 18:53, girish vaitheeswaran wrote:
> > > > > I am seeing a 20% slowdown with feedback optimization.
> > > > > Does anyone have any th
This is on Intel Pentium4 on Linux.
-girish
--- Janis Johnson <[EMAIL PROTECTED]> wrote:
> On Wed, Jul 20, 2005 at 10:45:01AM -0700, girish
> vaitheeswaran wrote:
> > > --- Steven Bosscher <[EMAIL PROTECTED]> wrote:
> > >
> > > > On Wednesday 20 July 2005 18:53, girish
> vaitheeswaran wrote:
>
On Wed, Jul 20, 2005 at 10:45:01AM -0700, girish vaitheeswaran wrote:
> > --- Steven Bosscher <[EMAIL PROTECTED]> wrote:
> >
> > > On Wednesday 20 July 2005 18:53, girish vaitheeswaran wrote:
> > > > I am seeing a 20% slowdown with feedback optimization.
> > > > Does anyone have any thoughts on th
I am using gcc 3.4.3
-girish
>
>
> --- Steven Bosscher <[EMAIL PROTECTED]> wrote:
>
> > On Wednesday 20 July 2005 18:53, girish
> > vaitheeswaran wrote:
> > > I am seeing a 20% slowdown with feedback
> > optimization.
> > > Does anyone have any thoughts on this.
> >
> > My first thought is th
On Wednesday 20 July 2005 18:53, girish vaitheeswaran wrote:
> I am seeing a 20% slowdown with feedback optimization.
> Does anyone have any thoughts on this.
My first thought is that you should probably first tell what compiler
you are using.
Gr.
Steven
I am seeing a 20% slowdown with feedback optimization.
Does anyone have any thoughts on this.
These are the steps I followed
1. Compiled the application using -fprofile-generate.
I used this flag both in the compile flags and as part
of the link flags. I also had to use libgcov.a during
the link p
31 matches
Mail list logo
