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

Hi all,

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) and I've got to the point where I 
have to deal with Qemu's use of global register variables. From what 
I've read LLVM doesn't support GCC style register variables and the 
workaround was to implement a custom calling convention to ensure they 
weren't clobbered (at least from a caller's point of view)[1]. I
haven't
played with the LLVM code base much, just used the interfaces, and so 
was wondering if anyone had some pointers on what to look at/how to go 
about this?

Cheers,

Andrew

[1] 
http://markmail.org/message/ko3rrf5zacoocvg5#query:+page:1+mid:5uygbscyiqmuxqi4+state:results

-------------- 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/ec1016d7/attachment.sig>

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?
> 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 - you just emit LLVM IR and let
the codegenerator deal with register allocation, etc. For example, you
have much available registers on x86-64 (and even on x86-32!).

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

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>