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: "David S. Miller" <davem at redhat dot com>
- Cc: 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: Wed, 22 May 2002 12:20:36 -0600
- Subject: Re: gcc 3.1 is still very slow, compared to 2.95.3
- Reply-to: law at redhat dot com
In message <20020519.045911.07995764.davem@redhat.com>, "David S. Miller" write
s:
> From: Jan Hubicka <jh@suse.cz>
> Date: Sun, 19 May 2002 13:52:06 +0200
>
> > Yes, it does optimize this, but into 3 byte stores. One of
> > which overlaps with the PUT_CODE (rt, code) rtx_alloc does.
> > :-(
>
> That is probably because GCC is unable to detect the alignment for some
> purpose. I don't see why :(
>
> I promise to look more deeply into this. It may be a Sparc specific
> problem because x86 outputs:
>
> movl $0, (%eax)
> movw code, (%eax)
>
> But I think GCC should really give us:
>
> movw $0, 2(%eax)
> movw code, (%eax)
>
> Well, better yet:
>
> movw code, (%eax)
> movw $0, 2(%eax)
>
> so it actually combines in the store buffer of the processor. (This
> is one area GCC really needs to improve, ordering consequetive stores
> to the same area)
>
> 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!
Can you send me rtl.i? I can take a quick peek at it.
jeff