similar to: [RFC] Attribute overhaul 2

There are two 64-bit bitmasks maintained in AttributeImpl.h<https://sdocc.itg.ti.com/ui#file:review=11893/version=393846>: - AvailableFunctionAttrs is part of the AttributeListImpl class, and - AvailableAttrs is part of the AttributeSetNode class Both of these assume that the number of available enum attributes is limited to 64. In fact, a static_assert in

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

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

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

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

I fell over this issue yesterday myself with lots of asserts being thrown. I think the issue is in lib/IR/AsmWriter.cpp:1618 in the function AssemblyWriter::printFunction(const Function *F) Looking at the code I think the 2nd for loop should be preceded by the test ... if (Idx < AS.getNumSlots()) Not sure why it doesn't fail on other platforms as it looks like it should be a genuine

Hi, Continuing recent efforts in understanding compile time slowdowns, I looked at some historical data: I picked one test and tried to pin-point commits that affected its compile-time. The data I have is not 100% accurate, but hopefully it helps to provide an overview of what's going on with compile time in LLVM and give a better understanding of what changes usually impact compile time.

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

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 >

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

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"

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 1/18/17 3:55 PM, Davide Italiano via llvm-dev wrote: > On Tue, Jan 17, 2017 at 6:02 PM, Mikhail Zolotukhin > <mzolotukhin at apple.com> wrote: >> Hi, >> >> Continuing recent efforts in understanding compile time slowdowns, I looked at some historical data: I picked one test and tried to pin-point commits that affected its compile-time. The data I have is not 100%

Ah but how did you compile the clang-4.0 you were using? Does it run faster if you compile it with clang-4.0? :) On Fri, Jan 20, 2017 at 4:09 AM, Mehdi Amini via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > On this topic, I just tried to build ToT with clang-3.9.1 and clang-4.0 > and the total time to complete `ninja clang` on this machine went from > 12m54s to

Hi, all. I want to give programmer ability to tell LLVM that certain region of code is expected to get specialized optimization. So, I'm trying to make custom pragma to mark certain region of code and pass this information to LLVM, in the similar way that '#pragma clang loop unroll_count(N)' works. By tracking the framework of loop unroll pragma, I found out it works in the way below.

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)

Yes. I checked that file, but I wasn't sure whether that is right one to look at. What is *.td extension btw? When I google it, it says this is for Windows Debug Simulator. Why clang use this extension, which is limited to Windows environment? On Tue, Oct 25, 2016 at 7:00 PM, Vedant Kumar <vsk at apple.com> wrote: > That file is generated by the clang-tblgen tool: > >

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