search for: dityperef

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

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 DITypeRef whe...

...8: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 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 ca...

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 cast it to > DITypeRef. > If I try to go inside the classes and use the pointer, I can cast, but > c...

> 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 cast it to DITypeRef. > If I try to go inside the classes and use the pointer, I can cast, but can't const...

...;> >> >> unspecified parameter in the type array and it is not a DIType. >> >> > >> >> > >> >> > I am going to work on a patch that adds DITypeArray (each element >> >> > will >> >> > be >> >> > DITypeRef, SubroutineType's type array will be DITypeArray) and adds >> >> > DITrivialType that extends from DIType (unspecified parameter will be >> >> > DITrivialType). >> >> > If you have opinions against it, please let me know, >> >> >>...

...; that for SubroutineType's type array instead. But we currently have >> >> unspecified parameter in the type array and it is not a DIType. >> > >> > >> > I am going to work on a patch that adds DITypeArray (each element will >> > be >> > DITypeRef, SubroutineType's type array will be DITypeArray) and adds >> > DITrivialType that extends from DIType (unspecified parameter will be >> > DITrivialType). >> > If you have opinions against it, please let me know, >> >> We haven't bothered using typed...

...ray are DITypes we can create a DITypeArray and use >> that for SubroutineType's type array instead. But we currently have >> unspecified parameter in the type array and it is not a DIType. > > > I am going to work on a patch that adds DITypeArray (each element will be > DITypeRef, SubroutineType's type array will be DITypeArray) and adds > DITrivialType that extends from DIType (unspecified parameter will be > DITrivialType). > If you have opinions against it, please let me know, We haven't bothered using typed arrays in DebugInfo yet (as you say, we just...

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

...a matter of whether pushing that library down into LLVM for other frontends to use would be good, which it probably will be at some point, so if it goes into Clang I'd at least try to keep it pretty well separated) Potentially that consistency could be created by going the other way - replace DITypeRef with an int, then have the retained types list be the int->type mapping. Skipping the mangled names. (& skip the retained types list for CV/PDB) - Dave On Wed, Mar 2, 2016 at 5:19 PM, Reid Kleckner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Circling back around 4 months...

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

...t code); and I'd imagined that the "types" part never referenced the "codegen" part. However it does in this case.) -- (the patches that increased memory from 27GB to 30GB) -------------- next part -------------- A non-text attachment was scrubbed... Name: 0006-IR-Remove-DITypeRef-DIScopeRef-and-DINodeRef-llvm.patch Type: application/octet-stream Size: 322088 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160418/bef754e6/attachment-0002.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: 0007-...

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

...his to handle ODR violations? We currently don't handle them, right - we just pick one instance of the type & the user gets to keep the pieces. Is there a particular motivation for changing that? Some place where it's more problematic, we have to support it, etc? > - 0006: Remove DITypeRef (string-based references) and strip down > 'retainedTypes:'. > > Once this is done, I expect the bitcode block layout improvements for > lazy-loading of subprograms and composite types (steps 3 and 5 from > this RFC) to be fairly straightforward. > > > > >...

...of both? * We should split it in two: Full declarations with type and a slimmed down version with an abstract origin. How will we reference types in the DWARF blob? * ODR types can be referenced by name * Non-odr types by full DWARF hash * Each type can be a pair(tuple) of identifier (DITypeRef today) and blob. * For < DWARF4 we can emit each type as a unit, but not a DWARF Type Unit and use references and module relocations for the offsets. (See below) How will we handle references in DWARF2 or global relocations for non-type template parameters? * We can use a “relocation” met...

...l declarations with type and a slimmed down version with an abstract origin. >> >> How will we reference types in the DWARF blob? >> * ODR types can be referenced by name >> * Non-odr types by full DWARF hash >> * Each type can be a pair(tuple) of identifier (DITypeRef today) and blob. >> * For < DWARF4 we can emit each type as a unit, but not a DWARF Type Unit and use references and module relocations for the offsets. (See below) >> >> How will we handle references in DWARF2 or global relocations for non-type template parameters? >&gt...

...of both? * We should split it in two: Full declarations with type and a slimmed down version with an abstract origin. How will we reference types in the DWARF blob? * ODR types can be referenced by name * Non-odr types by full DWARF hash * Each type can be a pair(tuple) of identifier (DITypeRef today) and blob. * For < DWARF4 we can emit each type as a unit, but not a DWARF Type Unit and use references and module relocations for the offsets. (See below) How will we handle references in DWARF2 or global relocations for non-type template parameters? * We can use a “relocation” met...

...ations with type and a slimmed >> down version with an abstract origin. >> >> How will we reference types in the DWARF blob? >> * ODR types can be referenced by name >> * Non-odr types by full DWARF hash >> * Each type can be a pair(tuple) of identifier (DITypeRef today) and >> blob. >> * For < DWARF4 we can emit each type as a unit, but not a DWARF Type >> Unit and use references and module relocations for the offsets. (See below) >> >> How will we handle references in DWARF2 or global relocations for >> non-type te...

...tions with type and a slimmed > down version with an abstract origin. > > > > How will we reference types in the DWARF blob? > > * ODR types can be referenced by name > > * Non-odr types by full DWARF hash > > * Each type can be a pair(tuple) of identifier (DITypeRef today) and > blob. > > * For < DWARF4 we can emit each type as a unit, but not a DWARF Type > Unit and use references and module relocations for the offsets. (See below) > > > > How will we handle references in DWARF2 or global relocations for non-type > template pa...