similar to: [LLVMdev] MAJOR API CHANGE: LLVMContext

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

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

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

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

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:

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

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

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

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

Dear LLVMers, LLVM is currently undergoing a change in its programming API, most of which has to do with the transition to using an LLVMContext. I've been trying to keep two LLVM projects, poolalloc and SAFECode, up-to-date with LLVM mainline, but it has become frustrating because: 1) The API changes occur frequently. Each morning I come in and have to fix something because the API

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

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

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

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

I hate to say it (because I already made the changes), but keeping compatibility with 2.5 is a good thing. -Rich 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

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 >

On Thu, Jul 23, 2009 at 7:35 PM, Owen Anderson<resistor at mac.com> 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 strictly

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,

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