Mapping registers into memory address

Hi all,

I’m working on using LLVM to generate ARM code for Android’s Dalvik VM.
I translated some DEX bytecode to LLVM IR, and now I wnat to translate these IR into ARM assembly by using llc.
But there are some ABI problems (Register mapping) should be solved.

Dalvik VM stores virtual register in the fixed memory address.
For example,
v0 → [r5,#0]
v1 → [r5,#4]
v2 → [r5,#8]
v3 → [r5,#12]

v100 → [r5,#400]

So I want to know how can I generate such register allocation?
(e.g load v3 from [r5,#12] and store v2 into [r5,#8])
I have got the approach for reserving r5, but load/store problem not yet
Is there any related information about it?
Thanks

Hi,

So I want to know how can I generate such register allocation?
(e.g load v3 from [r5,#12] and store v2 into [r5,#8])

I assume you don't actually have code generated for now then?

I have got the approach for reserving r5, but load/store problem not yet
Is there any related information about it?

The most similar case I'm aware of is the GHC calling convention on
X86. They have a bunch of fixed information passed in in registers to
each function. They've written a special calling convention that
"magically" allocates the information to the correct registers.

I think they may have experimented with fixed reserved registers to
begin with, but decided this implementation is actually better: it
allows LLVM to rearrange all those values if it really wants to for
efficiency, provided they're in the correct place at call boundaries.

In your case, what I'd probably do is make each function take a shadow
argument "i32* %vreg_base" which gets allocated to r5 by a special
calling convention (defined in ARMCallingConv.td; not that
complicated).

Then when generating IR you'd create something like:

define void @foo(i32* %vreg_base, i32 %arg1, i32 %arg2) {
    %vreg5addr = getelementptr i32* %vreg_base, i32 5
    %vreg5val = load i32* %vreg5addr
    [...]
}

Now, I'm not sure what the Dalvik runtime expects. With this scheme
LLVM may not keep r5 as the vreg_base *all* the time (just at function
call sites), which means if your function can be asynchronously
interrupted r5 may not be as expected. This may or may not be a
problem for you.

Let us know if you need other ideas or clarification.

Tim.