[LLVMdev] Integrating LLVM in an existing project
Reid Spencer
rspencer at reidspencer.com
Thu Apr 5 08:29:48 PDT 2007
On Thu, 2007-04-05 at 16:33 +0200, Nicolas Geoffray wrote:
> Hi Reid
>
> Reid Spencer wrote:
> >
> > Interesting project. I wish you could talk about it at the Developer's
> > Meeting (http://llvm.org/DevMtgMay2007.html :)
> >
> >
>
> I wish I could! Unfortunately there is very little chance I get the
> fundings to
> go to the US in May.
Yes, long way to go on short notice.
> >
> > I have signed up to implemented this (PR1269) just as Chris' note
> > states. HLVM needs it for much the same reason that VVM does. I hope to
> > address this in late April. I'm not sure if it will make it into the 2.0
> > release (if it does, it will be close).
> >
>
> That's great news! I'll look at the PR to see if I can help.
That would be welcome :)
> >> 2) The llvm.dbg.stoppoint: how far is it actually implemented?
> >>
> >
> > So, the question really is, how do you want to use this in the JIT?
> >
> >
>
> Didn't see that one coming :) Maybe I want to use it like I want to use
> basic blocs for getting addresses of instructions. My only concern is to
> be sure that a
> list of instruction is generated between one label and one other, and to
> know the
> addresses of these labels.
I don't think debug stop points are a very useful mechanism for this
purpose. I don't know if llvm supports taking the address of a label
since generally the only thing you can/should use it for is a
branch/switch. Can you do this kind of processing before code generation
(at the LLVM IR level) ?
If not, then please what for Chris or someone to chime in on the "can we
get the address of a basic block" issue.
You might also find this thread useful:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2004-August/001782.html
Reid.
>
> Thanks Reid!
>
> Best,
> Nicolas
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
More information about the llvm-dev
mailing list