similar to: [LLVMdev] New Attribute Group broke bitcode compatibility

Hi Nick, I have committed 0001 as r203788. I'm working on fixes for 0002 - 0014. > After reading through this patch series, I feel like I'm missing > something important. Where's the sort function? It looks like we're > still comparing all functions to all other functions. When you insert functions into std::set or its analogs it does all the job for you. Since

Hi Nick, I tried to rework changes as you requested. One of patches (0004 with extra assertions) has been removed. > + bool isEquivalentType(Type *Ty1, Type *Ty2) const { > + return cmpType(Ty1, Ty2) == 0; > + } > > Why do we still need isEquivalentType? Can we nuke this? Yup. After applying all the patches isEquivalentType will be totally replaced with cmpType. All

LLVM knows what all the types of the intrinsic functions are; I thought, why are users (including llvm-gcc...) required to duplicate all this information in order to use them? I mean in order to call getOrInsertFunction to get declarations for them. So I wrote this patch, which allows all this code to be generated automatically. Is this a good approach? Dan -- Dan Gohman, Cray Inc. <djg at

In IntrinsicEmitter::EmitTypeGenerate, called from IntrinsicEmitter::EmitGenerator, here for (unsigned j = 0; j != N; ++j) { OS << " ArgTys.push_back("; EmitTypeGenerate(OS, ParamTys[j], ArgNo); OS << ");\n"; } I'm hitting this assertion: if (ArgType->isSubClassOf("LLVMMatchType")) { unsigned Number =

That's a bug. I'm working on a fix.... On Apr 15, 2009, at 10:16 AM, Villmow, Micah wrote: > In IntrinsicEmitter::EmitTypeGenerate, called from > IntrinsicEmitter::EmitGenerator, here > for (unsigned j = 0; j != N; ++j) { > OS << " ArgTys.push_back("; > EmitTypeGenerate(OS, ParamTys[j], ArgNo); > OS << ");\n"; > }

On Mon, Feb 05, 2007 at 12:28:56PM -0800, Chris Lattner wrote: > On Mon, 5 Feb 2007, Dan Gohman wrote: > > > LLVM knows what all the types of the intrinsic functions are; I thought, > > why are users (including llvm-gcc...) required to duplicate all this > > information in order to use them? I mean in order to call > > getOrInsertFunction to get declarations for

> On Oct 25, 2016, at 6:28 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > Hi all, > > As mentioned in my recent RFC entitled "RFC: a more detailed design for ThinLTO + vcall CFI" I would like to introduce the ability for bitcode files to contain multiple modules. In https://reviews.llvm.org/D24786 <https://reviews.llvm.org/D24786> I took a step

On Oct 10, 2012, at 5:10 PM, Jan Voung <jvoung at chromium.org> wrote: > Thanks for the review Rafael! > > Chris, did you want to take a look at the patch too? Your most recent patch looks good to me, with a minor change: +++ b/lib/Bitcode/Writer/BitcodeWriter.cpp @@ -33,6 +33,13 @@ using namespace llvm; static cl::opt<bool>

> On Oct 28, 2016, at 2:21 PM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> >> On Oct 28, 2016, at 2:16 PM, Will Dietz <willdtz at gmail.com <mailto:willdtz at gmail.com>> wrote: >> >> On Fri, Oct 28, 2016 at 2:06 PM, Peter Collingbourne <peter at pcc.me.uk <mailto:peter at pcc.me.uk>> wrote: >>> On Fri,

Hi all, As mentioned in my recent RFC entitled "RFC: a more detailed design for ThinLTO + vcall CFI" I would like to introduce the ability for bitcode files to contain multiple modules. In https://reviews.llvm.org/D24786 I took a step towards that by proposing a change to the module format so that the block info block is stored at the top level. The next step is to think about what the

On Wed, Oct 26, 2016 at 2:04 PM, Peter Collingbourne via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On Tue, Oct 25, 2016 at 8:36 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: >> >> >> On Oct 25, 2016, at 6:28 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: >> >> Hi all, >> >> As mentioned in my recent RFC entitled

Hi Jan, > I've been looking into how to make llvm bitcode files smaller. There is one > simple change that appears to shrink linked bitcode files by about 15%. See > this spreadsheet for some rough data: > > https://docs.google.com/spreadsheet/ccc?key=0AjRrJHQc4_bddEtJdjdIek5fMDdIdFFIZldZXzdWa0E the improvement is wonderful! ... > In any case, the patch is attached if

Oops. That was premature. I think your original question was on the right track. TableGen distinguishes between known and "overloaded" types (like "llvm_anyfloat_ty" in your example). The overloaded types are numbered separately, and the argument to LLVMMatchType is an index into these overloaded types, ignoring the known types. So, in your case, the first

Hello, I'm using llvm for some experiments and I was wondering if you might be able to give me some more insight on what I'm planning to do. :) I would like to store some llvm ir to a custom bitcode format. (Let's say I have 5 different versions of very similar looking bitcode, where the only difference are the enum numbers of each bitcode (see /include/llvm/Bitcode/LLVMBitCodes.h))

On Tue, Apr 4, 2017 at 1:25 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Apr 4, 2017, at 12:12 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > On Mon, Apr 3, 2017 at 8:13 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> >> On Apr 3, 2017, at 7:08 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: >> >> Hi,

On Tue, Oct 25, 2016 at 8:36 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Oct 25, 2016, at 6:28 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > Hi all, > > As mentioned in my recent RFC entitled "RFC: a more detailed design for > ThinLTO + vcall CFI" I would like to introduce the ability for bitcode > files to contain multiple

Hi all. In the beginning of this method I see the next: for (unsigned i = 0, e = AttrGrps.size(); i != e; ++i) { AttributeSet AS = AttrGrps[i]; for (unsigned i = 0, e = AS.getNumSlots(); i != e; ++i) { AttributeSet A = AS.getSlotAttributes(i); Record.push_back(VE.getAttributeGroupID(A)); Record.push_back(AS.getSlotIndex(i)); for (AttributeSet::iterator I

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 Fri, Oct 28, 2016 at 2:06 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > On Fri, Oct 28, 2016 at 6:11 AM, Will Dietz <willdtz at gmail.com> wrote: >> >> On Wed, Oct 26, 2016 at 2:04 PM, Peter Collingbourne via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >> > On Tue, Oct 25, 2016 at 8:36 PM, Mehdi Amini <mehdi.amini at apple.com>

I still think there is a bug somewhere, but not sure where yet. This is what is generated in intrinsic.gen: case Intrinsic::opencl_math_fdistance: // llvm.opencl.math.fdistance ResultTy = Type::FloatTy; ArgTys.push_back(Tys[0]); ArgTys.push_back(Tys[0]); break; This is the intrinsic definition: def int_opencl_math_fdistance_fast : Intrinsic<[llvm_float_ty],