This is the mail archive of the
mailing list for the GCC project.
Re: AST optimizer in C++?
- From: Dave Hudson <dave at cyclicode dot net>
- To: Chris Lattner <sabre at nondot dot org>
- Cc: gcc at gcc dot gnu dot org
- Date: Sat, 24 Aug 2002 23:21:40 +0100
- Subject: Re: AST optimizer in C++?
- References: <Pine.LNX.email@example.com>
Chris Lattner wrote:
Fortunately for most quite small processors this isn't all that
difficult (generally quite few opcodes and a limited set of side effects).
On Sat, 24 Aug 2002, Dave Hudson wrote:
Unfortunately I don't have a really good solution for your binary
translation project: most of the hard stuff is interpreting the actual
machine instructions and figuring out side effects I imagine...
I have some hopes that the new register allocator might be able to do
better things for us, but in practice the current one doesn't make
things impossible - we simply have to rerun some of the earlier passes
again and undo some of the pessimization. Such code is actually quite
typical of code produced for 8-bit targets and consequently I still
think gcc a good choice. FWIW I can point to several quite large
functions (hundreds of opcodes) where I would be very hard-pressed to
identify more than a couple of opcodes that I could eliminate without
If this is the case, it may be that GCC isn't really the right compiler
for you to use. It really is designed for architectures with "enough"
registers, and that fit a certain design model. With only a single GPR,
you are probably better off using a custom register allocator, for
Loops just happen to be a very bad case (and I have a really good test
case that demonstrates just how silly things can be where one function
generates optimal code and another generates an extra 5 opcodes it the
middle of the loop - the rest of the loop is 3 opcodes). Fortunately
unlike most other gcc users I don't really have to worry if getting good
code takes another 60 passes over the RTL because when building a whole
application on a 900 MHz Athlon under Linux only takes 15s I'm not
I guess the other thing is that I get a certain satisfaction from
finding that I really can get gcc to do some tricks that other people
assured me I'd never get it to do. One particular favourite has been
getting it to use an unconditional skip instruction (unconditionally
skips the next opcode) and some pretty agressive jump threading to great
effect - currently about 0.1% of opcodes in our binaries are
uncoditional skips :-)