This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcc 3.1 is still very slow, compared to 2.95.3


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]