On Tue, 14 Aug 2007, Jay Foad wrote:> I'm looking at writing a custom backend targetting a proprietary
virtual
> machine. I'm basing it on the existing C and MSIL backends. My VM only
has
> 32- and 64-bit integer operations (like the JVM) but C code compiled with
> llvmgcc typically has lots of 1-, 8- and 16-bit instructions.
Ok.
> I was thinking of writing a custom pass to promote small integer types and
> instructions to 32-bits, adding sign- and/or zero-extension instructions
> where necessary. Does this sound reasonable?
Sure, that should be straight-forward.
> If my pass inserts sign/zero-extensions instructions naively then lots of
> them will probably turn out to be redundant. Can I run other optimization
> passes afterwards to remove the redundant instructions? Is there any danger
> that running other optimization passes will re-introduce 8- or 16-bit
> instructions?
This probably won't work well, because passes will reintroduce the shorter
instructions as they desire. You could write a simple thing that catches
the common cases though.
> Alternatively, I noticed that SelectionDAG::Legalize() already contains
code
> to promote small integer values, but I'm not sure how to take advantage
of
> it. If I use a SelectionDAG would I have to use all the rest of the target
> machinery that's designed for targetting real CPUs? Because I don't
think I
> want to use SelectionDAG-based instruction selection, and I certainly
don't
> want to do conventional register allocation.
I don't really think this will work. You can only really use the
selectiondag infrastructure if you plan to use the rest of the instruction
selection stuff. However, it would be possible to use the instruction
selection stuff to convert to machine instructions that correspond to your
VM, then convert the machine instructions to the output. In this way, you
could just use the selectiondag infrastructure we have as a lowering
system.
-Chris
--
http://nondot.org/sabre/
http://llvm.org/