similar to: [LLVMdev] Fwd: BitcodeWriter.cpp, WriteAttributeGroupTable attribute slot index is hardcoded.. ?

I am currently making some BitcodeWriter changes that involve some refactoring, and am thinking for the Nth time that it would be much nicer to have a class instead of passing around a long list of parameters. I am thinking of biting the bullet and doing that - any objections? I assume the reason why there is no existing class wrapping the bitcode writing process is just legacy code and nothing

> On 2016-Apr-21, at 11:41, Mehdi Amini <mehdi.amini at apple.com> wrote: > > >> On Apr 21, 2016, at 11:25 AM, Teresa Johnson <tejohnson at google.com> wrote: >> >> I am currently making some BitcodeWriter changes that involve some refactoring, and am thinking for the Nth time that it would be much nicer to have a class instead of passing around a long

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

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

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 >

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

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

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"

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

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

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

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"

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

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

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)