similar to: [LLVMdev] LLVMContext: Suggestions for API Changes

On Jul 15, 2009, at 7:44 AM, John Criswell wrote: > 1) If technically possible, add the new API first, get it working, > email > llvmdev describing the old and new APIs, provide some lead time for > people to change over, and then remove the old APIs. This makes it > easier to plan when I fix problems due to LLVM API changes and when I > can work on our own bugs. :) The

Owen Anderson wrote: > On Jul 15, 2009, at 7:44 AM, John Criswell wrote: > >> 1) If technically possible, add the new API first, get it working, >> email >> llvmdev describing the old and new APIs, provide some lead time for >> people to change over, and then remove the old APIs. This makes it >> easier to plan when I fix problems due to LLVM API changes

On Jul 15, 2009, at 9:53 AM, John Criswell wrote: > Owen Anderson wrote: >> On Jul 15, 2009, at 7:44 AM, John Criswell wrote: >> >>> 1) If technically possible, add the new API first, get it working, >>> email >>> llvmdev describing the old and new APIs, provide some lead time for >>> people to change over, and then remove the old APIs. This

Owen Anderson wrote: > > On Jul 15, 2009, at 9:53 AM, John Criswell wrote: > >> Owen Anderson wrote: >>> On Jul 15, 2009, at 7:44 AM, John Criswell wrote: >>> >>>> 1) If technically possible, add the new API first, get it working, >>>> email >>>> llvmdev describing the old and new APIs, provide some lead time for

Le 15 juil. 09 à 19:07, Owen Anderson a écrit : > > On Jul 15, 2009, at 9:53 AM, John Criswell wrote: > >> Owen Anderson wrote: >>> On Jul 15, 2009, at 7:44 AM, John Criswell wrote: >>> >>>> 1) If technically possible, add the new API first, get it working, >>>> email >>>> llvmdev describing the old and new APIs, provide some

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

Owen Anderson wrote: > On Jul 15, 2009, at 10:56 AM, Jean-Daniel Dupas wrote: >> >> You mean like this subject ? >> >> http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-June/023505.html > > Notice the sender line on that email... ;-) Yes, you indeed announced that change, but as John rightfully remarked, the announcement gave little detail. For LLVM users like me,

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

On Jul 15, 2009, at 10:56 AM, Jean-Daniel Dupas wrote: > > You mean like this subject ? > > http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-June/023505.html > Notice the sender line on that email... ;-) --Owen -------------- next part -------------- An HTML attachment was scrubbed... URL:

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

Dear All, Is there a reason why the AllocaInst constructor takes an LLVMContext argument? Can't it just determine the context from either the basic block or instruction pointer argument? If the constructor can infer the context automatically, that would save one API change. If the constructor can't infer it, would it be possible to make the context the last parameter and have it use a

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

On Wed, Jul 15, 2009 at 2:24 PM, Albert Graef<Dr.Graef at t-online.de> wrote: > Owen Anderson wrote: >> On Jul 15, 2009, at 10:56 AM, Jean-Daniel Dupas wrote: >>> >>> You mean like this subject ? >>> >>> http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-June/023505.html >> >> Notice the sender line on that email... ;-) > > Yes, you

On Wed, Jul 15, 2009 at 8:52 AM, Owen Anderson<resistor at mac.com> wrote: > > On Jul 15, 2009, at 8:14 AM, John Criswell wrote: > > Dear All, > > Is there a reason why the AllocaInst constructor takes an LLVMContext > argument?  Can't it just determine the context from either the basic > block or instruction pointer argument? > > BasicBlocks and

So, as you all probably noticed, the APIs for creating constants have been moved (or in a specific cases, are about to be moved) from static methods on Constant to instance methods on LLVMContext. However, as was recently pointed out on llvm-commits and on IRC, this is no longer strictly necessary. Because types have contexts, all of the constant subclasses could be friended to

Hi devs: I'm trying to do something quite simple, but it seems I need to provide an LLVMContext& to do it. I'm not sure what the 'proper' LLVMContext would be in my situation. I'm writing an analysis that is a FunctionPass. At some point in the pass, I am given a Value * representing an N-bit integer. My goal is to contruct two ConstantInt instances, for comparison

On Jul 15, 2009, at 8:14 AM, John Criswell wrote: > Dear All, > > Is there a reason why the AllocaInst constructor takes an LLVMContext > argument? Can't it just determine the context from either the basic > block or instruction pointer argument? BasicBlocks and Instructions don't necessarily have contexts, if they're not attached to a module. You can also

Dear Owen, Are passes supposed to grab the LLVMContext from the Module/Function/BasicBlock passed into their runOn<Module/Function/BasicBlock> method, or is the PassManager supposed to set the pass's Context member variable automatically? I thought it was the latter, but after an SVN update of LLVM, my passes have a NULL Context, and the LLVM code looks like the passes are all setting

Hi, 1 vote in favour of sticking with the 2.5 API Mark. Owen Anderson wrote: > So, as you all probably noticed, the APIs for creating constants have > been moved (or in a specific cases, are about to be moved) from static > methods on Constant to instance methods on LLVMContext. > > However, as was recently pointed out on llvm-commits and on IRC, this is > no longer

Nicholas, > What if I want to have global llvm::Type's, that can be used by many > LLVMContext's. For example, I'd like to have one LLVMContext per > function, and be able to create constants that belong to the context > but using a global, shared amongst LLVMContext's, llvm::Type. > > I know that's not doable right now, but aren't we losing this >