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


"David S. Miller" wrote:
> 
>    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]

Sure, fixing this might reduce your insn count, but my point was
it's killing you with L1 w misses.  Can you skip the initialisation?

How many of those words will get dragged into L1 D and then never
read or written again?

Is this something that 2.95.3 also does, but 3.1's multiple allocation
areas makes much worse?

J


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