Re: profiles of gcc available

Richard Henderson (richard@atheist.tamu.edu)
Tue, 12 Nov 1996 22:48:38 -0600 (CST)

> However, all this information rather overwhelms me - perhaps we can
> simplify things a bit. A compiler is (roughly) some program that
> reads a text file (i.e. a stream of bytes), transforms that to an
> intermediate representation (tree structure, in gcc's case),
> manipulates that tree of structures (optimisation passes) and writes
> the assembler output (again a stream of bytes).

The thing is, see, is gcc really doesn't spend that much time playing
with the bytes. According to Jim's profiles, 4.5% of the time is spent
playing with incoming bytes (yylex); after that we always play with
tokens (ints). Unfortunately there is no single output function making
it hard to say exactly how much time is spent that way, but I don't think
I'm off in saying it isn't much.

> Now neither bytes,
> nor the members of the various structures used in gcc internally,
> are necessarily long- or quadwords (i.e. 32 or 64 bit quantities).

I suppose they needn't have been but they are. Virtually everything
done inside of gcc once things are parsed are with pointers and longs.

No, the thing to do to make gcc faster is not to worry about the I/O,
but to improve the algorithms used in the optimization phases.

r~

--
To unsubscribe: send e-mail to axp-list-request@redhat.com with
'unsubscribe' as the subject.  Do not send it to axp-list@redhat.com



Feedback | Store | News | Support | Product Errata | About Us | Linux Info | Search | JumpWords
No Frames | Show Frames

Copyright © 1995-1997 Red Hat Software. Legal notices