similar to: [LLVMdev] Question about changes to llvm::Argument::addAttr(AttributeSet AS) API

On Jan 30, 2013, at 8:20 PM, Christian Schafmeister <chris.schaf at verizon.net> wrote: > > Hi, > > I recently upgraded to the latest LLVM build and encountered a problem where the API for Argument::addAttr has changed. > > Previously it was Argument::addAttr(Attribute A) and I was able to work with this. > > The latest build has changed the method addAttr so

On Feb 4, 2013, at 11:54 PM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > On 5 Feb 2013, at 01:32, Bill Wendling wrote: > >> No. It hasn't been written up. We typically don't do write-ups for API changes. However, we do list the thing we do change in the ReleaseNotes (these changes haven't made it there though). > > The attributes API has

LLVM's Attribute APIs need an overhaul. Current problems ================ First, testing for an attribute on an Argument is slow. llvm::AttributeSet::getAttributes(int) consumed 2% of cycles while optimizing llc during LTO. Our mid-level optimizations are constantly asking if a given argument has some attribute (nonnull, dereferencable, etc), and this is currently linear in the size of the

On 5 Feb 2013, at 01:32, Bill Wendling wrote: > No. It hasn't been written up. We typically don't do write-ups for API changes. However, we do list the thing we do change in the ReleaseNotes (these changes haven't made it there though). The attributes API has undergone a horrendous amount of churn over the last few months, both before and after the 3.2 release. I've lost

On 6 Feb 2013, at 07:50, Bill Wendling wrote: > On Feb 4, 2013, at 11:54 PM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > >> On 5 Feb 2013, at 01:32, Bill Wendling wrote: >> >>> No. It hasn't been written up. We typically don't do write-ups for API changes. However, we do list the thing we do change in the ReleaseNotes (these changes

On Feb 7, 2013, at 12:14 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > On 6 Feb 2013, at 20:20, Bill Wendling wrote: > >> You don't understand what I'm saying. The APIs were changing way too quickly for it to make sense to create such a document. I tried as best as I could to mitigate all of the problems, but there were several intermediate steps that had

On 6 Feb 2013, at 20:20, Bill Wendling wrote: > You don't understand what I'm saying. The APIs were changing way too quickly for it to make sense to create such a document. I tried as best as I could to mitigate all of the problems, but there were several intermediate steps that had to happen before the attributes classes were in a proper state for the new feature work. The typical way

On 7 Feb 2013, at 22:25, Bill Wendling wrote: >>> You don't understand what I'm saying. The APIs were changing way too quickly for it to make sense to create such a document. I tried as best as I could to mitigate all of the problems, but there were several intermediate steps that had to happen before the attributes classes were in a proper state for the new feature work. The

On Feb 7, 2013, at 6:23 PM, 陳韋任 (Wei-Ren Chen) <chenwj at iis.sinica.edu.tw> wrote: > Hi Bill, > > Just my 2 cents. How about sent a "HEADS UP" message to the ML > before you make changes. You can say "Hey, if you're using those > API I am going to change, please wait until I say everything is > stable." I think David can wait until you say the

On Feb 8, 2013, at 12:59 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > On 7 Feb 2013, at 22:25, Bill Wendling wrote: > >>>> You don't understand what I'm saying. The APIs were changing way too quickly for it to make sense to create such a document. I tried as best as I could to mitigate all of the problems, but there were several intermediate steps

On 8 Feb 2013, at 09:53, Chandler Carruth wrote: > I also think you should remember that it is explicitly *not* a goal of the LLVM project to optimize its development process for out-of-tree projects, and instead it *is* a goal to optimize the development process for in-tree efforts. >From the front page of the LLVM web site, point number 1: > • The LLVM Core libraries provide a modern

On Feb 6, 2013, at 2:31 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > On 6 Feb 2013, at 07:50, Bill Wendling wrote: > >> On Feb 4, 2013, at 11:54 PM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: >> >>> On 5 Feb 2013, at 01:32, Bill Wendling wrote: >>> >>>> No. It hasn't been written up. We typically

Using the New Attributes Classes Attributes in LLVM have changed in some fundamental ways. It was necessary to do this to support expanding the attributes to encompass more than a handful of attributes --- e.g. command line options. The old way of handling attributes consisted of representing them as a bit mask of values. This bit mask was stored in a "list" structure that was reference

> However, we do list the thing we do change in the ReleaseNotes Unfortunately this doesn't actually seem to be the case. -- Sean Silva

Hi Bill, Just my 2 cents. How about sent a "HEADS UP" message to the ML before you make changes. You can say "Hey, if you're using those API I am going to change, please wait until I say everything is stable." I think David can wait until you say the changes are done and done, please sync with TOT. How about that, David? Regards, chenwj -- Wei-Ren Chen (陳韋任)

On Feb 6, 2013, at 2:02 AM, Óscar Fuentes <ofv at wanadoo.es> wrote: > Bill Wendling <wendling at apple.com> writes: > > [snip] > >> Welcome to living on the top-of-tree! :-) >> >> We are in between releases. It's expected that the APIs will be >> unstable. [snip] > > One thing is an unstable API, and a different thing is a code base

Bill Wendling <wendling at apple.com> writes: [snip] > Welcome to living on the top-of-tree! :-) > > We are in between releases. It's expected that the APIs will be > unstable. [snip] One thing is an unstable API, and a different thing is a code base where an API change is introduced gradually. From the POV of users, the latter is more like a pre-alpha stage API. Using

----- Original Message ----- > From: "James Molloy via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Vaivaswatha Nagaraj" <vn at compilertree.com> > Cc: "LLVM Dev" <llvm-dev at lists.llvm.org> > Sent: Thursday, December 3, 2015 4:41:46 AM > Subject: Re: [llvm-dev] Function attributes for LibFunc and its impact on GlobalsAA > >

On Feb 6, 2013, at 2:42 AM, Óscar Fuentes <ofv at wanadoo.es> wrote: > Bill Wendling <wendling at apple.com> writes: > >> Using a development branch and then slamming those changes into trunk >> is at odds with the llvm style incremental development philosophy. > > In this case, the LLVM incremental style is counterproductive, for both > users and

On Feb 7, 2013, at 2:25 PM, Bill Wendling <wendling at apple.com> wrote: > On Feb 7, 2013, at 12:14 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > >> The comment on other VCSs seems irrelevant, but if you are making such invasive changes that they must be done in multiple passes then either a feature branch and a merge or a local git clone seem the correct