[LLVMdev] Global register variables/custom calling conventions
andrew at aj.id.au
Tue Sep 22 22:26:25 PDT 2009
Anton Korobeynikov wrote:
> Ok, what's left from QEMU then? :)
The hardware emulation (interrupts, condition flags, register file etc)
and execution framework (block selection and execution) from qemu are
still used - translating the ARM to the native architecture is only part
of the story :)
>> generating reasonable code - this approach keeps it in place while we do
>> extra, possibly more expensive work out of sight. It might not be a pretty
>> idea, but LLVM does generate some very tight code :) It's an experiment -
>> humour me...
> Well, but I still don't get the reason why you need to pin (some)
> internal QEMU state variables to fixed registers?
TCG seperates the guest (ARM) code into blocks - my front end translates
these to LLVM IR for LLVM to translate to x86. The assumption is that
LLVM will produce a better translation than TCG*. At some future point
the TCG-generated native block is replaced by the LLVM's, and as such it
needs to hand control back to qemu in a state that it would expect from
TCG. Essentially the idea is to take the same input and produce the same
output as the original TCG block, but munge things in the middle to
(hopefully) be more efficient using LLVM's local optimisations.
All up, the the LLVM generated code needs to conform to what qemu is
expecting from TCG in terms of emulated register state, and, as it's
pinning values in host registers, some parts of the host register state.
The pinned register in this case holds a pointer to the emulated cpu's
state structure as it's frequently accessed. Clobbering this would break
things such as direct block chaining (which avoids the need to jump out
to the dispatch loop to find the next block to execute) and possibly
other parts of the execution framework.
Hope it makes some sense :)
* At this point the frontend only supports a few ARM instructions, and
it avoids generating IR that could lead to positional dependence. The
general approach has the nice property that if an instruction that isn't
implemented is encountered, the block simply isn't translated by LLVM
and the TCG version lives on.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 261 bytes
Desc: OpenPGP digital signature
More information about the llvm-dev