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: rth 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 23:48:40 -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.214154.56367623.davem@redhat.com>, "David S. Miller" write
s:
> From: Richard Henderson <rth@redhat.com>
> Date: Sun, 19 May 2002 15:18:55 -0700
>
> 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.
>
> Could it be yet more fallout from that Kenner change that was
> being discussed a few weeks ago? That is where I was going to
> start snooping around when I got back to this...
Possible, though the PA generates similar code and it's a STRICT_ALIGNMENT
target. If it were something that generic, I'd expect the PA to have
issued a bunch of byte stores like the sparc.
jeff