similar to: [LLVMdev] Using the New Attributes Classes

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 >

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

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

Hi everyone, Nick and Philip suggested something yesterday that I'd also thought about: supporting attributes on values (http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140908/234323.html). The primary motivation for this is to provide a way of attaching pointer information, such as noalias, nonnull and dereferenceable(n), to pointers generated by loads. Doing this for pointers

> 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

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

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

Hi all, Is there an efficient way to construct an AttributeSet for the purpose of constructing a Function? The only (public) way I've found to designate the parameter index of attributes is via the addAttribute methods of the Function class or the AttributeSet. This is quite inefficient as a new AttributeSet is constructed every time. In fact, it takes the bulk of the time my codegen

Hello! clang defines some AttributeSet, for example: attributes #0 = { nounwind uwtable "less-precise-fpmad"="false" "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf"="true" "no-infs-fp-math"="false" "no-nans-fp-math"="false" "unsafe-fp-math"="false"

On Sep 3, 2013, at 9:04 AM, Raul Fernandes Herbster <raulherbster at gmail.com> wrote: > Hello! > > clang defines some AttributeSet, for example: > > attributes #0 = { nounwind uwtable "less-precise-fpmad"="false" "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf"="true"

> On Mar 24, 2016, at 12:45 PM, Xiangyang Guo via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, > > When I define an intrinsic function with memory write permission, my assumption is that we can either attach [IntrReadWriteArgMem] or [] to the intrinsic function. Based on the comment of the source code , "IntrReadWriteArgMem - This intrinsic reads and writes

Hi, Not sure whether this matches your use case, but the Orc-based JIT used in LLI appears to be using `llvm::orc::LocalCXXRuntimeOverrides` (http://llvm.org/doxygen/classllvm_1_1orc_1_1LocalCXXRuntimeOverrides.html) to override `__cxa_atexit`: https://github.com/llvm-mirror/llvm/blob/release_50/tools/lli/OrcLazyJIT.h#L74

This addition converts strlen() calls to strnlen() when the result is compared to a constant. For example, the following: strlen(s) < 5 Becomes: strnlen(s, 5) < 5 That way, we don't have to walk through the entire string. There is the added overhead of maintaining a counter when using strnlen(), but I thought I'd start with the general case. It may make sense to only use this

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 ignore it. So, to be able to *flag* my functions I’m trying to add a *real* attribute to clang. I’ve added a new attribute to clang in tools/clang/include/clang/Basic/Attr.td: def NoFLA : Attr { let Spellings =

Hi, When I define an intrinsic function with memory write permission, my assumption is that we can either attach [IntrReadWriteArgMem] or [] to the intrinsic function. Based on the comment of the source code , "IntrReadWriteArgMem - This intrinsic reads and writes only from memory that one of its arguments points to, but may access an unspecified amount." "If no property is set,

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

I did a RelWithDebInfo + asserts build of LLVM just now and, when running "make check" under Valgrind, am seeing a lot of uses of uninitialized memory like the one below. Anyone know offhand what's likely to be the root cause? Unfortunately a Debug build doesn't give these errors. Thanks, John FAIL: LLVM :: Analysis/BasicAA/pr18573.ll (2093 of 18733)

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 Mon, Jan 5, 2015 at 1:40 AM, Pete Cooper <peter_cooper at apple.com> wrote: > Hi lx, Philip > > I've seen an instcombine which helps with this situation. It fires when > the function types on both sides of the bitcast have the same number of > operands and compatible types. It then adds bitcasts on the arguments and > removes the one on the called function. > It