similar to: [LLVMdev] Building function parameter AttributeSets quickly

These were requested by Bill Wendling to simplify a Mips 16 clang change. The test is in the code in Clang which uses these for mips 16. -------------- next part -------------- Index: include/llvm/IR/Function.h =================================================================== --- include/llvm/IR/Function.h (revision 176874) +++ include/llvm/IR/Function.h (working copy) @@ -181,6 +181,14 @@

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

Very nice! Could we get this write-up added to the sphinx docs? On Sat, Feb 9, 2013 at 11:41 AM, Bill Wendling <wendling at apple.com> wrote: > 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 >

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

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

Dear LLVM developers, Our team has developed an LLVM-based protection mechanism that (i) prevents control-flow hijack attacks enabled by memory corruption errors and (ii) has very low performance overhead. We would like to contribute the implementation to LLVM. We presented this work at the OSDI 2014 conference, at several software companies, and several US universities. We received positive

> On 24 Mar 2015, at 14:55, Aaron Ballman <aaron at aaronballman.com> wrote: > > On Tue, Mar 24, 2015 at 9:48 AM, Rinaldini Julien > <julien.rinaldini at heig-vd.ch> wrote: >> Hi, >> >> I want to *tag* some functions with some *flags*. I was using annotate((“myFlag”)) and everything was working fine until I tried on ObjC method. It seems that clang just

Hi Vesa, The pass IndVars changes the induction variables to allow SCEV to analyze them and enable other optimizations. This is the canonicalization phase. Later on, LSR lowers the canonicalized induction variables to induction variables that map nicely to the target's addressing modes. In many cases it can remove some of the induction variables. I suspect that the loop vectorizer does

On Feb 19, 2013, at 10:09 AM, Vesa Norilo <vnorilo at siba.fi> wrote: > Hi Nadav and Hal and thanks for the help! > > To the best of my understanding, indvars doesn't complain and an induction variable is detected. However, the loop vectorizer says: > > LV: Checking a loop in "add_vector" > LV: Found a loop: Loop > LV: Found an induction variable. >

Hi Nadav and Hal and thanks for the help! To the best of my understanding, indvars doesn't complain and an induction variable is detected. However, the loop vectorizer says: LV: Checking a loop in "add_vector" LV: Found a loop: Loop LV: Found an induction variable. LV: Found an unidentified PHI. %a.ptr = phi float* [ %a, %Top ], [ %a.next, %Loop ] LV: Can't vectorize the

----- Original Message ----- > From: "Vesa Norilo" <vnorilo at siba.fi> > To: llvmdev at cs.uiuc.edu > Sent: Tuesday, February 19, 2013 4:40:26 AM > Subject: [LLVMdev] Auto-vectorization and phi nodes > > Hi all, > > Sorry if this is a dumb or FAQ or the wrong list! > > I'm currently investigating LLVM vectorization of my generated code. > My

Dear All, Under the old attribute API, when we modified the alignment attribute of a byval argument in a caller or callee, we first removed the old alignment attribute and then added a new alignment attribute. With the new API, can I just use the AttrBuilder to build the alignment attribute and then use the addAttribute() method of CallInst and Argument to overwrite the old alignment

Hello. I'm writing an LLVM pass that is working on LLVM IR. To my surprise the following LLVM pass code generates optimized code - it does copy propagation on it. Value *vecShuffleOnePtr = Builder.CreateGEP(ptr_B, vecShuffleOne, "VectorGep"); ... packed_gather_params.push_back(vecShuffleOnePtr); CallInst *callGather =

Hi all, Sorry if this is a dumb or FAQ or the wrong list! I'm currently investigating LLVM vectorization of my generated code. My codegen emits a lot of recursions that step through arrays via pointers. The recursions are nicely optimized into loops, but the loop vectorization can't seem to work on them because of phi nodes that point to gep nodes. Some simple IR to demonstrate; it

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 Dec 30, 2016, at 3:03 PM, Alex Susu via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hello. > I'm writing an LLVM pass that is working on LLVM IR. > To my surprise the following LLVM pass code generates optimized code - it does copy propagation on it. It does *constant* propagation to be exact. > Value *vecShuffleOnePtr = Builder.CreateGEP(ptr_B,

On Nov 20, 2012, at 11:03 AM, Meador Inge <meadori at codesourcery.com> wrote: > On Nov 13, 2012, at 12:20 AM, Bill Wendling wrote: > >> IR Changes >> ---------- >> >> The attributes will be specified within the IR. This allows us to generate code >> that the user wants. This also has the advantage that it will no longer be >> necessary to specify

> On Jul 14, 2015, at 4:48 PM, Reid Kleckner <rnk at google.com> wrote: > > This sounds more like a use case for metadata. Can we attach metadata to function arguments, or does that not work currently? We can’t, no. I have an out of tree patch which allows metadata in AttributeSets. This would also potentially also work here. However, depending on the number of unique

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

On Tue, Jul 14, 2015 at 9:01 PM Philip Reames <listmail at philipreames.com> wrote: > On 07/14/2015 05:07 PM, Pete Cooper wrote: > > > On Jul 14, 2015, at 4:48 PM, Reid Kleckner <rnk at google.com> wrote: > > This sounds more like a use case for metadata. Can we attach metadata to > function arguments, or does that not work currently? > > We can’t, no.