--- Comment #22 from steven at gcc dot gnu dot org 2006-01-07 18:33 ---
I compiled the test case nodom.c with "xgcc (GCC) 4.1.0 20060107 (prerelease)"
and ran the resulting executables with "time ./a.out". And the numbers speak
for themselves:
x86-64 (Nocona):
=
--- Comment #21 from steven at gcc dot gnu dot org 2006-01-07 18:23 ---
Using ``.ident "GCC: (GNU) 4.1.0 20060107 (prerelease)"'' on AMD64 with -m32,
I get the following assembly outputs:
options: -O2 -fno-tree-dominator-opts
.L2:
movl$videoram, %eax
movl$-2, %e
--- Comment #20 from pinskia at gcc dot gnu dot org 2006-01-03 15:54
---
4.2.0 produces good code on x86 also.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #17 from law at redhat dot com 2005-11-10 18:30 ---
Subject: Re: [4.1 Regression] Slowdown of the
bresenham line drawing by roughly 20%
On Wed, 2005-11-02 at 14:32 +, hubicka at ucw dot cz wrote:
> Hmm, perhaps restricting the reassociation + simplification into
--- Comment #16 from law at redhat dot com 2005-11-10 18:26 ---
Subject: Re: [4.1 Regression] Slowdown of the
bresenham line drawing by roughly 20%
On Wed, 2005-11-02 at 14:32 +, hubicka at ucw dot cz wrote:
> Hmm, perhaps restricting the reassociation + simplification int
--- Comment #15 from hubicka at ucw dot cz 2005-11-02 14:32 ---
Subject: Re: [4.1 Regression] Slowdown of the bresenham line drawing by
roughly 20%
>
>
> --- Comment #13 from law at redhat dot com 2005-10-31 23:36 ---
> Subject: Re: [4.1 Regression] Slowdown of the
>
>
>
> --- Comment #13 from law at redhat dot com 2005-10-31 23:36 ---
> Subject: Re: [4.1 Regression] Slowdown of the
> bresenham line drawing by roughly 20%
>
> On Mon, 2005-10-31 at 23:25 +, hubicka at ucw dot cz wrote:
>
> > See comment #5. The fact that we ended up wi
--- Comment #14 from law at redhat dot com 2005-11-01 22:24 ---
Subject: Re: [4.1 Regression] Slowdown of the
bresenham line drawing by roughly 20%
On Mon, 2005-10-31 at 04:36 +, mmitchel at gcc dot gnu dot org
wrote:
>
> --- Comment #9 from mmitchel at gcc dot gnu dot
--- Comment #13 from law at redhat dot com 2005-10-31 23:36 ---
Subject: Re: [4.1 Regression] Slowdown of the
bresenham line drawing by roughly 20%
On Mon, 2005-10-31 at 23:25 +, hubicka at ucw dot cz wrote:
> See comment #5. The fact that we ended up with more jumps was
--- Comment #12 from hubicka at ucw dot cz 2005-10-31 23:25 ---
Subject: Re: [4.1 Regression] Slowdown of the bresenham line drawing by
roughly 20%
>
>
> --- Comment #11 from law at redhat dot com 2005-10-31 23:18 ---
> Subject: Re: [4.1 Regression] Slowdown of the
>
>
>
> --- Comment #11 from law at redhat dot com 2005-10-31 23:18 ---
> Subject: Re: [4.1 Regression] Slowdown of the
> bresenham line drawing by roughly 20%
>
> On Mon, 2005-10-31 at 20:55 +, hubicka at gcc dot gnu dot org wrote:
> >
> > --- Comment #10 from hubicka a
--- Comment #11 from law at redhat dot com 2005-10-31 23:18 ---
Subject: Re: [4.1 Regression] Slowdown of the
bresenham line drawing by roughly 20%
On Mon, 2005-10-31 at 20:55 +, hubicka at gcc dot gnu dot org wrote:
>
> --- Comment #10 from hubicka at gcc dot gnu dot
--- Comment #10 from hubicka at gcc dot gnu dot org 2005-10-31 20:55
---
Jeff, you missed the propagation DOM makes that hurts register allocation
indpeendently on whether code sinking does or does not it's job.
In reality code sinking (that appeared in GCC after I reported the bug)
imp
--- Comment #9 from mmitchel at gcc dot gnu dot org 2005-10-31 04:36
---
So, Jeff, is it your opinion that this is just an inevitable case of
optimizers-aren't-perfect? If so, would you please just close this PR?
Leaving as P2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23181
14 matches
Mail list logo