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: Richard Henderson <rth at redhat dot com>
- To: law at redhat dot com
- Cc: jseward at acm dot org, "David S. Miller" <davem at redhat dot com>, neil at daikokuya dot demon dot co dot uk, gcc at gcc dot gnu dot org, njn25 at cam dot ac dot uk
- Date: Sun, 19 May 2002 15:15:50 -0700
- Subject: Re: gcc 3.1 is still very slow, compared to 2.95.3
- References: <3CE78FCF.5F0F7249@acm.org> <15878.1021826299@porcupine.cygnus.com>
On Sun, May 19, 2002 at 10:38:19AM -0600, law@redhat.com wrote:
> > > On Sparc this is:
> > >
> > > stb %g0, [%rt + 1]
> > > sth code, [%rt]
> > > stb %g0, [%rt + 2]
> > > stb %g0, [%rt + 3]
> > >
> > > When it should be optimized into:
> > >
> > > sth code, [%rt]
> > > sth %g0, [%rt + 2]
Or rather
sethi %hi(code << 16), tmp
st tmp, [rt]
> Right now we have:
> memset (rt, 0, sizeof (struct rtx_def) - sizeof (rtunion));
>
> We could to do something like this, but unfortunately you can't take the
> address of a bitfield:
>
> memset (&rt->mode, 0, &rt->fld[0] - &rt->mode);
We should simply fix the compiler so that it knows how to
merge the stores.
r~