[LLVMdev] Bind a LLVM variable to a CPU register

[Bill Kelly]

John Criswell wrote:
> 
> 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.

Not meaning to hijack the thread, but I'd encountered this issue when
considering how to implement a two-stack Forth-like language
interpreter with LLVM.

It has been common for an old-school Forth implementation to keep the
data stack pointer in a register; and some implementations additionally
kept the top-of-stack value in its own register.

As for the TOS-in-register optimization, I've no doubt it would be far
preferable to allow the LLVM optimizer to make such decisions --
at least assuming we're building a "subroutine threaded" implementation
where compiled definitions consist of actual IR instructions for LLVM
to optimize, rather than lists of addresses for the interpreter to
fetch and call.

But regarding the data stack pointer itself, it does feel a bit weird
to be passing the pointer around as an 'argument' to every primitive.
(And putting the data stack pointer in a global would impose a single-
threaded model on the interpreter.)

That said, i suspect that if one were to design an interpreter for
such a language with LLVM's strengths in mind -- such as ability to
inline primitives combined with IR optimization passes -- that having
to pass the data stack pointer as an 'argument' to all primitives
wouldn't amount to an actual issue of concern.

However if one were attempting to implement a more traditional Forth-
style interpreter such as a direct threaded VM, where LLVM would be
unable to optimize the IR beyond the level of each individual non-
inlineable primitive, then I figure not being able to dedicate a
register to the data stack pointer would be likely significant.

(Although why someone would want to implement the latter in LLVM
apart from as an exercise, I don't know.)

I still hope to get around to trying the former someday: inlineable
primitives, optimization, and passing the data stack as an argument,
and see what the optimized IR looks like.


Regards,

Bill