A faster instruction selector?

Choosing the fast selector does speed code-generation by almost double,
when using llc, but the reduction in final code speed is obviously a
downside.

[...]

Since my toolkit generates an interpreter, I am able to just compile
hotspots, so final speed of compiled code is quite important.

I recommend doing some measurements here rather than
guessing. I note that you've posted several numbers comparing
compile times with lcc, but no numbers comparing the quality of
the generated code yet :-).

Of course, llvm generated code is faster :slight_smile:
But lcc doesn't do many optimisations and uses a fairly simple local register allocator.
However, the lburg instruction selector is optimal (for trees, not for DAGs) and very fast. It was a fast instruction selector for llvm
that I was hoping for, the optimisation passes and register allocator are already quite fast.

Do you have time to do more detailed profiling? It might be interesting
to see which parts of codegen are hot in your use cases.

Unfortunately I could get any meaningful information from valgrind as to
where llc is spending its time (Unknown code: 45%), but I suspect the
relative slowness is caused by the number of intermediate data
structures required and the time spent in creating them.

On some hosts LLVM defaults to being built with -fomit-frame-pointer,
and this interferes with some performance tools, so that's something
worth checking.

I'll rebuild llvm with symbols and frame-pointer and try to get some useful profile data. I get back to you when I've done so.
Probably in a week or two.

This would also be a good time to sanity check that you're using an
optimized build of LLVM, which can make a tremendous difference.
FWIW, the default mode for LLVM Makefiles is non-optimized.

Yes, I am running the optimised version

Finally, it must be possible to select the register allocator for the
JIT using the API, but I am unable to find out how to do this, any ideas?

See RegAllocRegistry.h and RegisterRegAlloc::setDefault.

Thanks

Dan

Seasons Greetings,
Mark.