The Cliffs of Inanity

Sat, 06 May 2006

Another One

Today I wrote another optimization pass for gcj. This one collapses equivalent vtable references and array length references. You'd think that GCC itself would do this, but there's no way to tell the optimizers that a given field is write-once.

Really I should fix GCC to do this... but writing a new pass is easy to do, and fixing the generic code looks daunting.

The other day I also rewrote my devirtualization pass to use the SSA propagation engine. Again, simple to do, and it improved the results a bit.

Hacking GCC these days, while still tricky in some details, is just enormously simpler than it was 5 years ago. Kudos to all the tree-ssa folks who made this happen.

ecj

I spent some time this week hooking ecj up to gcj, as threatened. I've got a new driver for the eclipse compiler that eases the argument processing a bit. This is working well enough now that I was able to successfully compile some source code using generics by running the gcj driver.

If only I had a decent place to check this in. I wonder if the SC would let me make a branch for this, even though it is in political limbo.

JIT etc.

I started writing my GCC optimizer passes because I was curious about writing a devirtualization pass for LLVM. I wrote about half of it and then thought that surely this would be just as simple for tree-ssa.

I've been thinking a bit about heuristics for when the libgcj JIT should recompile. The easy ones are things like: recompile when classes are initialized, so we can remove initialization calls from inside loops; and recompile when constant pool references are resolved, so we can replace expensive indirect accesses with cheap direct ones.

There's probably a lot of literature out there that I should be reading on other times this is worthwhile -- detecting when partial specialization is worthwhile, profile-directed runtime optimization, etc. Maybe HLVM will help.

Actually doing the recompilation is simple; LLVM provides the needed hooks. For things like constant pool references, I think I will take the simple approach of simply re-lowering from bytecode to LLVM. If this proves to be too expensive, it can always be changed, I think. But I suspect it won't be. And, anyway, it will be fun finding out.

posted at: 14:11 | path: /software | permanent link to this entry