Notice of a major upcoming API change: The static methods for constructing types and constants will be going away in the future. Instead, the global uniquing tables that lurk behind these APIs will be privatized within LLVMContext instances. What this means for you: Your client application will need to create an LLVMContext in main(), and pass it into a few APIs (the constructor for Module, for instance). You can, in theory, have more than one LLVMContext as long as you never want Modules created under separate contexts to interact. In the near term, I will be committing patches to do this conversion for the existing LLVM tools, including Clang and LLVM-GCC, which should provide examples for those following along at home. --Owen
To ease this transition, I have added a getGlobalContext() API. If you're only ever planning to use LLVM on a single thread, it will be completely safe to simply pass this value to every API that takes an LLVMContext. --Owen On Jun 30, 2009, at 3:38 PM, Owen Anderson wrote:> Notice of a major upcoming API change: The static methods for > constructing types and constants will be going away in the future. > Instead, the global uniquing tables that lurk behind these APIs will > be privatized within LLVMContext instances. > > What this means for you: Your client application will need to create > an LLVMContext in main(), and pass it into a few APIs (the constructor > for Module, for instance). You can, in theory, have more than one > LLVMContext as long as you never want Modules created under separate > contexts to interact. > > In the near term, I will be committing patches to do this conversion > for the existing LLVM tools, including Clang and LLVM-GCC, which > should provide examples for those following along at home. > > --Owen > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Hello Owen, Is this effective immediately for the 2.6 Top of Tree or is it something that will change in the next release (eg. 2.7)? Thanks, --Sam ----- Original Message ----> From: Owen Anderson <resistor at mac.com> > To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Sent: Tuesday, June 30, 2009 7:14:03 PM > Subject: Re: [LLVMdev] MAJOR API CHANGE: LLVMContext > > To ease this transition, I have added a getGlobalContext() API. If > you're only ever planning to use LLVM on a single thread, it will be > completely safe to simply pass this value to every API that takes an > LLVMContext. > > --Owen > > On Jun 30, 2009, at 3:38 PM, Owen Anderson wrote: > > > Notice of a major upcoming API change: The static methods for > > constructing types and constants will be going away in the future. > > Instead, the global uniquing tables that lurk behind these APIs will > > be privatized within LLVMContext instances. > > > > What this means for you: Your client application will need to create > > an LLVMContext in main(), and pass it into a few APIs (the constructor > > for Module, for instance). You can, in theory, have more than one > > LLVMContext as long as you never want Modules created under separate > > contexts to interact. > > > > In the near term, I will be committing patches to do this conversion > > for the existing LLVM tools, including Clang and LLVM-GCC, which > > should provide examples for those following along at home. > > > > --Owen
That's awesome, thanks very much for working on this Owen. So if I understand correctly, there can be as many LLVMContext instances as we want? Or one module only has a single LLVMContext? A similar question is: can I now delete constants created, after JIT-compiling a function's IR? I know we can already delete the body of the function, but not the constants the body needs. So can we do that now? Thanks! Nicolas Owen Anderson wrote:> Notice of a major upcoming API change: The static methods for > constructing types and constants will be going away in the future. > Instead, the global uniquing tables that lurk behind these APIs will > be privatized within LLVMContext instances. > > What this means for you: Your client application will need to create > an LLVMContext in main(), and pass it into a few APIs (the constructor > for Module, for instance). You can, in theory, have more than one > LLVMContext as long as you never want Modules created under separate > contexts to interact. > > In the near term, I will be committing patches to do this conversion > for the existing LLVM tools, including Clang and LLVM-GCC, which > should provide examples for those following along at home. > > --Owen > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
On Jun 30, 2009, at 7:38 PM, Nicolas Geoffray wrote:> That's awesome, thanks very much for working on this Owen. So if I > understand correctly, there can be as many LLVMContext instances as we > want? Or one module only has a single LLVMContext?You can have as many modules per context as you wish, and as many contexts as you wish. Modules belonging to different contexts are essentially isolated from each other. You can't, for now at least, link them together or anything. It might be possible in the future, but it will be significantly heavier weight than linking two modules in the same context.> A similar question is: can I now delete constants created, after > JIT-compiling a function's IR? I know we can already delete the body > of > the function, but not the constants the body needs. So can we do > that now?I'm honestly not sure, and this is not an explicit goal of the LLVMContext work. Patches are welcome, though. :-) --Owen
Owen Anderson wrote:> Notice of a major upcoming API change: The static methods for > constructing types and constants will be going away in the future. > Instead, the global uniquing tables that lurk behind these APIs will > be privatized within LLVMContext instances. > > What this means for you: Your client application will need to create > an LLVMContext in main(), and pass it into a few APIs (the constructor > for Module, for instance). You can, in theory, have more than one > LLVMContext as long as you never want Modules created under separate > contexts to interact. > > In the near term, I will be committing patches to do this conversion > for the existing LLVM tools, including Clang and LLVM-GCC, which > should provide examples for those following along at home. >Can you give a brief example of where to find the LLVMContext within a ModulePass or FunctionPass? Is this just the context stored within the Module or Function passed to runOnModule/runOnFunction? If the above is true, then does the GlobalVariable constructor need to take a Context argument? It seems it should be able to infer it from the Module argument. -- John T.> --Owen > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
On Jul 8, 2009, at 7:57 AM, John Criswell wrote:> Owen Anderson wrote: > Can you give a brief example of where to find the LLVMContext within a > ModulePass or FunctionPass? Is this just the context stored within > the > Module or Function passed to runOnModule/runOnFunction?Passes have a protected Context member, which is set for them by the PassManager, if you don't override doInitialization. If you do, yes, you can fetch it from the Module or the Function.> If the above is true, then does the GlobalVariable constructor need to > take a Context argument? It seems it should be able to infer it from > the Module argument.The GlobalVariables can be (and are, for the create_sentinel() methods) constructed with null for the Module argument. --Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090708/e790aa1b/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2620 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090708/e790aa1b/attachment.bin>