This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: gcc 3.1 is still very slow, compared to 2.95.3
- From: law at redhat dot com
- To: Richard Henderson <rth at redhat dot com>
- Cc: "David S. Miller" <davem at redhat dot com>, jh at suse dot cz, neil at daikokuya dot demon dot co dot uk, jseward at acm dot org, gcc at gcc dot gnu dot org, njn25 at cam dot ac dot uk
- Date: Sun, 19 May 2002 19:13:02 -0600
- Subject: Re: gcc 3.1 is still very slow, compared to 2.95.3
- Reply-to: law at redhat dot com
In message <20020519151855.C6055@redhat.com>, Richard Henderson writes:
> On Sun, May 19, 2002 at 04:59:11AM -0700, David S. Miller wrote:
> > I promise to look more deeply into this. It may be a Sparc specific
> > problem because x86 outputs:
> >
> > movl $0, (%eax)
> > movw code, (%eax)
>
> No, x86 does this because !STRICT_ALIGNMENT. Somehow we've lost
> the known alignment of the type during the memset.
>
> > Well, better yet:
> >
> > movw code, (%eax)
> > movw $0, 2(%eax)
>
> Again, better yet
>
> movl code, (%eax)
>
> > The Sparc output is very perplexing because GCC eliminated one of
> > the byte stores that overlapped the store of "code" but not both
> > of them!
>
> That is curious. I'd have expected the dead store elimination
> code in flow to be able to handle that.
Na. The stores are different sized, which prevents the optimization
even though they use the same address. Not terribly difficult to fix.
jeff