llvm dev - Sep 2009 - [LLVMdev] Global register variables/custom calling conventions

Anton Korobeynikov wrote:
> Hello
> 
>> I'm implementing an LLVM backend for qemu-arm (by creating an ARM
frontend
>> for LLVM - from what I understand a slightly different approach than
the
>> original llvm-qemu project)
> I don't see the difference so far. Could you please explain?
Again, from what I understand, llvm-qemu worked by emitting LLVM IR from 
QEMU IR API calls. This project goes straight from ARM to LLVM IR, 
bypassing QEMU's IR, (partially) in the hope that more information about 
the original intent of the code is retained. I don't have any numbers 
handy for comparison against the argument "it'd optimise away",
however,
we have to have an implementation to test this theory anyway ;)
> 
>> and I've got to the point where I have to deal with Qemu's use
of global register variables.
> Why? The whole point of llvm-qemu project was that you don't need to
> go with all that hacks and workarounds
The point of this is to provide an alternative backend to QEMU that can 
be run in a separate thread to generate optimised blocks, while working 
as transparently as possible. A nice property of TCG (QEMU's current 
JIT, which was dyngen when llvm-qemu was written) is that it's extremely 
fast at 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...

Sorry if this is somewhat OT.

Cheers,

Andrew

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20090920/e52618eb/attachment.sig>

Hello
> Again, from what I understand, llvm-qemu worked by emitting LLVM IR from
> QEMU IR API calls. This project goes straight from ARM to LLVM IR,
bypassing
> QEMU's IR, (partially) in the hope that more information about the
original
> intent of the code is retained.
Ok, what's left from QEMU then? :)
> 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?

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

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

Cheers,

Andrew

* 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...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20090923/f831a415/attachment.sig>