This is the mail archive of the 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: AST optimizer in C++?

Hi Chris,

Chris Lattner wrote:
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...
Fortunately for most quite small processors this isn't all that difficult (generally quite few opcodes and a limited set of side effects).

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
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 inter-procedural analysis.

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 over-worried :-)

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 :-)


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