search for: dityperefs

On 07/25/2015 08:57 PM, Andrew Wilkins wrote: > On Sun, 26 Jul 2015 at 06:48 Rodney M. Bates <rodney_bates at lcwb.coop <mailto:rodney_bates at lcwb.coop>> wrote: > > In trying to write a C binding for DIBuilder of llvm 3.6.1, I can't see a way to unwrap > llvm::DITypeRef, declared in include/llvm/IR/DebugInfo.h. This is a class with one > data member, a

In trying to write a C binding for DIBuilder of llvm 3.6.1, I can't see a way to unwrap llvm::DITypeRef, declared in include/llvm/IR/DebugInfo.h. This is a class with one data member, a pointer to Metadata. If I try to make my C type a struct with one pointer, I can't cast it to DITypeRef. If I try to go inside the classes and use the pointer, I can cast, but can't construct a

On 07/27/2015 10:59 AM, Rodney M. Bates wrote: > > > On 07/25/2015 08:57 PM, Andrew Wilkins wrote: >> On Sun, 26 Jul 2015 at 06:48 Rodney M. Bates <rodney_bates at lcwb.coop <mailto:rodney_bates at lcwb.coop>> wrote: >> >> In trying to write a C binding for DIBuilder of llvm 3.6.1, I can't see a way to unwrap >> llvm::DITypeRef, declared in

On Sun, 26 Jul 2015 at 06:48 Rodney M. Bates <rodney_bates at lcwb.coop> wrote: > In trying to write a C binding for DIBuilder of llvm 3.6.1, I can't see a > way to unwrap > llvm::DITypeRef, declared in include/llvm/IR/DebugInfo.h. This is a class > with one > data member, a pointer to Metadata. > > If I try to make my C type a struct with one pointer, I can't

> On 2015-Jul-25, at 15:44, Rodney M. Bates <rodney_bates at lcwb.coop> wrote: > > In trying to write a C binding for DIBuilder of llvm 3.6.1, I can't see a way to unwrap > llvm::DITypeRef, declared in include/llvm/IR/DebugInfo.h. This is a class with one > data member, a pointer to Metadata. > > If I try to make my C type a struct with one pointer, I can't

...positeType::getTypeArray() will return DITypeArray and >> > DITypeArray::getElement(unsigned) will return DITypeRef. >> > >> > This is actually more complicated than I thought, not all >> > DICompositeType's >> > getTypeArray() can return an array of DITypeRefs. For example, >> > getTypeArray() of ArrayType and VectorType can not return an array of >> > DITypeRefs. >> >> Why can't they? > > > For ArrayType, we create it like this: > SmallVector<llvm::Value *, 8> Subscripts; > ... > Subscripts.pus...

...ted, where all elements are DITypeRef), > DICompositeType::getTypeArray() will return DITypeArray and > DITypeArray::getElement(unsigned) will return DITypeRef. > > This is actually more complicated than I thought, not all DICompositeType's > getTypeArray() can return an array of DITypeRefs. For example, > getTypeArray() of ArrayType and VectorType can not return an array of > DITypeRefs. Why can't they? > We can fix that by extending DICompositeType to DISubroutineType and only > DISubroutineType::getTypeArray() will return DITypeArray. > Even for SubroutineType,...

On Mon, Jul 21, 2014 at 10:39 AM, Manman Ren <manman.ren at gmail.com> wrote: > > > > On Mon, Jul 14, 2014 at 11:32 AM, Manman Ren <manman.ren at gmail.com> wrote: >> >> >> We still have access to types via MDNodes directly and the assertion that >> assumes all accesses to DITypes are accessing the resolved DIType will fire >> >> i.e

We still have access to types via MDNodes directly and the assertion that assumes all accesses to DITypes are accessing the resolved DIType will fire i.e assert(Ty == resolve(Ty.getRef())) One example is the access to DIType via DIArray in SubroutineType. If all elements in the type array are DITypes we can create a DITypeArray and use that for SubroutineType's type array instead. But we

I think it'd be reasonable to at least figure out a good way to do type references consistently across the two schemes, but I'm OK with the idea of having a blob of opaque type information for different debug info formats, created by frontends (& don't mind if the library for building that blob live in LLVM or Clang for now - the DWARF one at least would probably live in LLVM

...he subprogram declaration is in a different file in one definition - that'd make the composite type itself different (metadata uniquing - composite type references the subprogram, etc). But we should only every find one version of the type (all references to the type should be via string-based dityperefs). Sure, we'll pick one at random, but when/how would we get two? > > > > > - 0006: Remove DITypeRef (string-based references) and strip down > > 'retainedTypes:'. > > > > Once this is done, I expect the bitcode block layout improvements for >...

...s in a different file in one definition - that'd make the composite type itself different (metadata uniquing - composite type references the subprogram, etc). >> > >> > But we should only every find one version of the type (all references to the type should be via string-based dityperefs). Sure, we'll pick one at random, but when/how would we get two? >> >> We get two because one of the modules contributes a definition of S::foo, >> and it may be pointing at the declaration from a version of S that isn't >> blessed. If you reverse the RUN line in t...

I have no objections to any of this FWIW :) -eric On Tue, Mar 29, 2016 at 6:46 PM Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > > On 2016-Mar-22, at 20:11, Eric Christopher <echristo at gmail.com> wrote: > > > >> On Tue, Mar 22, 2016 at 8:04 PM David Blaikie <dblaikie at gmail.com> > wrote: > >> +pcc, who had some other

...different file in one definition - that'd make the composite type itself > different (metadata uniquing - composite type references the subprogram, > etc). > > > > But we should only every find one version of the type (all references to > the type should be via string-based dityperefs). Sure, we'll pick one at > random, but when/how would we get two? > > We get two because one of the modules contributes a definition of S::foo, > and it may be pointing at the declaration from a version of S that isn't > blessed. If you reverse the RUN line in the in-tree t...

On Fri, Apr 15, 2016 at 9:50 AM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > Since I haven't heard any objections to the direction, I'm planning to > commit this (step 4) when I find some cycles; likely over the weekend. > > To make this more concrete (in case someone is silently concerned) I've > posted my WIP patches below. They apply cleanly to

Hi All, This is something that's been talked about for some time and it's probably time to propose it. The "We" in this document is everyone on the cc line plus me. Please go ahead and take a look. Thanks! -eric Objective (and TL;DR) ================= Migrate debug type information generation from the backends to the front end. This will enable: 1. Separation of

Hi Eric, I'm coming back on this topic after discussing this offline quickly with Reid, and at length with Adrian, Duncan, and Fred. I may have to take back some of my words from my previous email, especially as it is not clear how and why what Reid is proposing to do is hurting a future path for Dwarf. Especially, if my understanding is correct, the key point that differentiate what Reid is

Skipping a serialization and doing something clever about LTO uniquing sounds awesome. I'm guessing you achieve this by extracting types out of DI metadata and packaging them as lumps-o-DWARF that the back-end can then paste together? Reading between the lines a bit here. Can you share data about how much "pure" types dominate the size of debug info? Or at least the current

On Tue, Mar 29, 2016 at 7:31 PM Peter Collingbourne <peter at pcc.me.uk> wrote: > Thanks for sharing this. Mostly seems like a reasonable plan to me. A few > comments below. > > Thanks Peter! > On Tue, Mar 29, 2016 at 6:00 PM, Eric Christopher via cfe-dev < > cfe-dev at lists.llvm.org> wrote: > >> Hi All, >> >> This is something that's been

On Tue, Mar 29, 2016 at 11:20 PM Robinson, Paul < Paul_Robinson at playstation.sony.com> wrote: > Skipping a serialization and doing something clever about LTO uniquing > sounds awesome. I'm guessing you achieve this by extracting types out of > DI metadata and packaging them as lumps-o-DWARF that the back-end can then > paste together? Reading between the lines a bit