Dan,
Hi,
I need to get the address of a label in jitted code.
(This is so that I can insert a jump into the machine code to resume interpretation from compiled code)Hello,
What's your plan for restoring register and memory state?
Put everything in memory at the yield point,
(its for x86 only at the moment).
Not super efficient, but should work.
So how do I get the address? 
Cheers,
Mark.
Hi Mark,
Dan was asking a loaded question. The answer is that LLVM doesn't support taking the address of a label because of the question he asked.
— Gordon
Gordon Henriksen wrote:
I need to get the address of a label in jitted code. (This is so that I can insert a jump into the machine code to resume interpretation from compiled code)
What's your plan for restoring register and memory state?
Put everything in memory at the yield point, (its for x86 only at the moment). Not super efficient, but should work.
So how do I get the address?
Hi Mark,
Dan was asking a loaded question. The answer is that LLVM doesn't support taking the address of a label because of the question he asked.
So how does llvm.dbg.stoppoint work?
Or does it? I can't seem to get anywhere with it.
And how do the VMKit people support line number info for the JVM?
I really need to get the machine addresses of particular points in the code, and I don't want to have to hack the x86 machine code emitter
or introduce my own intrinsics.
Mark
Is your interpreter stackless? If it's stackless, you can put
your entrypoint at the beginning of a Function, and then just
call it.
LLVM doesn't support taking the real address of a label. It may
some day, but that won't by itself make it safe to jump into
compiled code from separately-compiled code. To do that, you'd
need to arrange some stable set of assumptions about the state
of the machine at the time of the jump, and a way to tell the
code generator where and how to stay within the assumptions.
And that's essentially what function calling conventions
already are.
Dan
Dan Gohman wrote:
Dan,
Hi,
I need to get the address of a label in jitted code.
(This is so that I can insert a jump into the machine code to resume
interpretation from compiled code)Hello,
What's your plan for restoring register and memory state?
Put everything in memory at the yield point,
(its for x86 only at the moment).
Not super efficient, but should work.Is your interpreter stackless? If it's stackless, you can put
your entrypoint at the beginning of a Function, and then just
call it.
No it has a stack, but I can guarantee that the ENTIRE state of the VM is recoverable. (I force all variables into memory at the yield point).
And I need to insert the jump at runtime, but only under certain conditions, so I don't want to split the code into sub-functions.
LLVM doesn't support taking the real address of a label. It may
some day, but that won't by itself make it safe to jump into
compiled code from separately-compiled code. To do that, you'd
need to arrange some stable set of assumptions about the state
of the machine at the time of the jump, and a way to tell the
code generator where and how to stay within the assumptions.
And that's essentially what function calling conventions
already are.
I can guarantee correctness, I just need to be able to get that address!
Please answer the question, I answered yours
Mark.
I did. The answer is LLVM doesn't support it.
The other answer is that patches to add support for this would
be welcome, even if we remain unconvinced about the specific
use case you're proposing. From LLVM's perspective, it would be
valuable as a way to generate more efficient code for GCC's
labels-as-values extension.
Dan
Mark Shannon wrote:
So how does llvm.dbg.stoppoint work?
Or does it? I can't seem to get anywhere with it.
And how do the VMKit people support line number info for the JVM?
We don't support it. The complexity of implementing it in LLVM does not worth the ability to print a line number (for now).
I really need to get the machine addresses of particular points in the code,
So, really, you *can't* right now. I definitely hope that one day LLVM will be able to do that, just for your simple case, or getting line numbers or doing dynamic on stack replacement.
Nicolas
Dan & Nicolas,
Thanks for your replies.
One more thing though,
How does llvm.dbg.stoppoint work?
Either it's not implemented (in which case perhaps it should be removed), or it must store a code address somewhere, and that is the information I want.
Finally,
I would love to implement a llvm.dbg.address_here(), or similar intrinsic, but I don't think I can justify the time 
Cheers,
Mark.