search for: addattr

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 that it requires an AttributeSet argument (Argument::addAttr(AttributeSet AS). I'm not sure how to adjust to this change. The AttributeSet object...

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 that it requires an AttributeSet argument (Argument::addAttr(AttributeSet AS). > Yes. > I'm not sure how to adjust to...

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

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

..., const char* ifName) { /* Convert from the standrad numbers and dots notation to binary data */ inet_aton("192.168.51.0", (struct in_addr *)&rinfo->dstAddr); inet_aton("192.168.51.90", (struct in_addr *)&rinfo->gateWay); } int addAttr (struct nlmsghdr *nlhdr, int maxlen, int type, void *data, int alen) { struct rtattr *rta; int len = RTA_LENGTH(alen); if (NLMSG_ALIGN(nlhdr->nlmsg_len) + len > maxlen) return -1; rta = (struct rtattr*)((char *)nlhdr + NLMSG_ALIG...

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 developers. Who is interested on watching your API going through intermediate stages and (possibly) experimental

...+ > > + /// setStructRetAttr - Set true to give the Argument a sret > > attribute. > > + void setStructRetAttr(bool byVal); > > These prototypes are all misleading; the bool value is ignored. I > think it would be preferable to simply have a single pair of methods, > addAttr(ParamAttr Attr) and removeAttr(ParamAttr Attr). > > > Index: include/llvm-c/Core.h > > =================================================================== > > --- include/llvm-c/Core.h (revision 50213) > > +++ include/llvm-c/Core.h (working copy) > > @@ -69,6 +69,8...

Bill Wendling <wendling at apple.com> writes: >> In this case, the LLVM incremental style is counterproductive, for both >> users and developers. Who is interested on watching your API going >> through intermediate stages and (possibly) experimental points until it >> stabilizes? >> > People who are interested in catching errors quickly before they >

...: lib/VMCore/Core.cpp > =================================================================== > --- lib/VMCore/Core.cpp (revision 50213) > +++ lib/VMCore/Core.cpp (working copy) > +void LLVMSetParamAlignment(LLVMValueRef Arg, unsigned align) > +{ > + unwrap<Argument>(Arg)->addAttr( > + ParamAttr::constructAlignmentFromInt(align)); > +} > + ... > +void LLVMSetInstrParamAlignment(LLVMValueRef Instr, unsigned index, > unsigned align) { > + CallSite Call = CallSite(unwrap<Instruction>(Instr)); > + Call.setParamAttrs( > + Call.getPara...

...; =================================================================== > > --- lib/VMCore/Core.cpp (revision 50213) > > +++ lib/VMCore/Core.cpp (working copy) > > +void LLVMSetParamAlignment(LLVMValueRef Arg, unsigned align) > > +{ > > + unwrap<Argument>(Arg)->addAttr( > > + ParamAttr::constructAlignmentFromInt(align)); > > +} > > + > > ... > > > +void LLVMSetInstrParamAlignment(LLVMValueRef Instr, unsigned index, > > unsigned align) { > > + CallSite Call = CallSite(unwrap<Instruction>(Instr)); > &g...

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 Fri, Feb 8, 2013 at 12:59 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk > wrote: > I have tracked the last three rewrites of the Attributes APIs in some > out-of-tree code and in none of them have I see any documentation > describing how to migrate from the old APIs. > I sympathize with your desire for more documentation of the end-state APIs David, but I think

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

...iasAttr(bool noAlias); > + > + /// setStructRetAttr - Set true to give the Argument a sret > attribute. > + void setStructRetAttr(bool byVal); These prototypes are all misleading; the bool value is ignored. I think it would be preferable to simply have a single pair of methods, addAttr(ParamAttr Attr) and removeAttr(ParamAttr Attr). > Index: include/llvm-c/Core.h > =================================================================== > --- include/llvm-c/Core.h (revision 50213) > +++ include/llvm-c/Core.h (working copy) > @@ -69,6 +69,8 @@ > typedef struct LLVMO...

Hi.. Updated so you now set alignment through LLVMInstrSetAlignment. Anders Johnsen -------------- next part -------------- A non-text attachment was scrubbed... Name: ParamAttr.patch Type: text/x-diff Size: 7420 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080424/cb72b4bb/attachment.patch>