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

[law at redhat dot com]

In message <20020519.010648.47187206.davem@redhat.com>, "David S. Miller" write
s:
 >    From: Neil Booth <neil@daikokuya.demon.co.uk>
 >    Date: Sun, 19 May 2002 08:07:03 +0100
 >    
 >    Results John posted had memset very high on the list, so I suspect
 >    someone is.  I think every tree and rtx allocated is memset to
 >    zero.
 > 
 > What overkill, it's clearing out one word. 
 > 
 > When optimizing, GCC should turn that into an inline
 > store into the first word of the rtx though....
 > 
 > (Dave checks...)
 > 
 > Yes, it does optimize this, but into 3 byte stores.  One of
 > which overlaps with the PUT_CODE (rt, code) rtx_alloc does.
 > :-(
 > 
 > 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]
On the PA we get:

  24:   0f 80 12 80     stw r0,0(sr0,ret0)
  28:   0f 84 12 40     sth r4,0(sr0,ret0)
  

ie, we store "0" (%r0) into the full word, then overwrite the first half of
the word with the "code" (%r4).

Something looks very hokey with your sparc code.   The compiler is acting
as if the data is potentially unaligned -- I suspect that's why you're getting
store-byte instructions.

jeff