similar to: [LLVMdev] RFC: Constant Creation API

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

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

Hi Owen, 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 possibility if we move back to

On Jul 23, 2009, at 7:35 PM, 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 strictly necessary. Because

On Jul 23, 2009, at 11:56 PM, Jeffrey Yasskin wrote: > 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.

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 >

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

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 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

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 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

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

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

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

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,

> On Mar 15, 2016, at 4:56 PM, Philip Reames via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Er, LoadValue's been around for a while (6 months). How far back are you testing? I'd strongly suggest switching to something more recent. Some of us have to support internal release branches for non-trivial amounts of time. —Owen -------------- next part -------------- An

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