[LLVMdev] Bind a LLVM variable to a CPU register

[Xin Tong]

On Thu, Jul 19, 2012 at 4:04 PM, John Criswell <criswell at illinois.edu> wrote:
> On 7/19/12 2:52 PM, Xin Tong wrote:
>>
>> On Thu, Jul 19, 2012 at 2:28 PM, John Criswell <criswell at illinois.edu>
>> wrote:
>>>
>>> On 7/19/12 1:23 PM, Jim Grosbach wrote:
>>>>
>>>> Not really, no.
>>>
>>>
>>> If you really, really, wanted to do it, you could:
>>>
>>> 1) Hack the code generator to not use that register.  It might be as
>>> simple
>>> as modifying the TableGen file to not know that the register exists.
>>> 2) Use inline asm to put the constant into that register and fetch it
>>> from
>>> that register.
>>>
>>> The real question is: what larger goal are you trying to accomplish?
>>> Holding a constant value in a register might not be the best way to do
>>> what
>>> you're doing.
>>>
>> I am using LLVM as the code generator for my system emulator. I need
>> one register holding the address of the CPUState struct.  most of the
>> emulation code is generated by LLVM. a small amount of code is not (
>> typically binary patched) . I must make sure that i know in which
>> register is the CPUState held when i am patching some code.
>
>
> Is there just one CPUState struct for the entire simulator, or are there
> multiple CPUState structures (e.g., one per simulated CPU) and you want to
> keep them handy because you use them all the time?
>
> If it's the former, why not just use a global variable?
>
> If it's the latter, there's probably a few options:
There are more than one emulated CPUs.
>
> 1) Use a thread-local global variable.  Each simulated process is a thread.
>
> 2) Store the CPUState struct at the bottom or top of the stack.  To get a
> pointer to it, mask some bits off the stack pointer using inline asm code.
> The Linux kernel uses this hack to find the process structure of the
> user-space process running on the current CPU.

these 2 are definitely possible ways. but the CPU pointer is used
extensively over the JITed emulation code. every use might need a mov
to a register on x86.

>
> 3) Change the code generator.  I don't work with the code generator, so I
> don't know how involved the change is, but I suspect it's pretty small.
>
I think i will go this way. i would agree with you that the changes
might be small.
> -- John T.
>