search for: diref

...quot;, i32 3, i64 8, i64 8, i32 0, i32 0, null, metadata !2, i32 0, null, metadata !7, metadata !”_ZTSN4test4TestIiEE”} > > I think we will need to have some kind of first-come-first-serve policy when it comes to the decl_file/decl_line of namespaces. The way to implement this would be to use DIRefs for namespaces. I'm not sure what you're getting at/why this would be necessary. If you break the reference to the type itself, it won't matter that sometimes the type is defined in a different place, will it? For example, the following patch (actually only the first part is needed f...

>> Without needing to change how namespaces are handled. >> >> Yes, using DIRefs for namespaces would cause the actual type nodes to >> be deduplicated when they aren't even with the patch above, and that >> would help reduce debug info metadata further if that's >> useful/necessary. > > Exactly. While the above patch will cover up the problem,...

+Adrian & Manman, Looks like this is a case of non-DIRef references ending up in the IR, and thus the references not being deduplicated. This could lead to some of the IR bloat that you guys implemented the DIRef stuff to reduce/avoid. The specific issue is that the type is slightly different in the two TUs (since the namespace scope it's contained...

...2014, at 4:39 PM, Adrian Prantl <aprantl at apple.com> wrote: > > >> On Jun 24, 2014, at 4:34 PM, Eric Christopher <echristo at gmail.com> wrote: >> >>>> Without needing to change how namespaces are handled. >>>> >>>> Yes, using DIRefs for namespaces would cause the actual type nodes to >>>> be deduplicated when they aren't even with the patch above, and that >>>> would help reduce debug info metadata further if that's >>>> useful/necessary. >>> >>> Exactly. While th...

...m> wrote: >>> >>> >>>> On Jun 24, 2014, at 4:34 PM, Eric Christopher <echristo at gmail.com> wrote: >>>> >>>>>> Without needing to change how namespaces are handled. >>>>>> >>>>>> Yes, using DIRefs for namespaces would cause the actual type nodes to >>>>>> be deduplicated when they aren't even with the patch above, and that >>>>>> would help reduce debug info metadata further if that's >>>>>> useful/necessary. >>>>>...

...t; >>>>>> On Jun 24, 2014, at 4:34 PM, Eric Christopher <echristo at gmail.com> wrote: >>>>>> >>>>>>>> Without needing to change how namespaces are handled. >>>>>>>> >>>>>>>> Yes, using DIRefs for namespaces would cause the actual type nodes to >>>>>>>> be deduplicated when they aren't even with the patch above, and that >>>>>>>> would help reduce debug info metadata further if that's >>>>>>>> useful/necessa...

Hi all, sorry to post to both lists, but I'm running into an issue where clang-generated debug info is deemed to be invalid by LLVM tools (throws an assertion error in both llc and mcjit), and I'm not sure what the proper resolution is. Here's a test case; I last tested it on revision r210953: $ cat test1.cpp #include "test.h" test::Test<int> foo1() { return

...Type. > I was mistaken. This does not solve my problem. The implicit conversion operator DITypeRef converts from a DIType, which can contain only an MDNode*, but I need to construct a DITypeRef, which can contain a Metadata*. The constructor I need is here: template <typename T> class DIRef { template <typename DescTy> friend DescTy DIDescriptor::getFieldAs(unsigned Elt) const; friend DIScopeRef DIScope::getContext() const; friend DIScopeRef DIScope::getRef() const; friend class DIType; /// \brief Val can be either a MDNode or a MDString. /// /// In the...

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

...9;, >> one in each CU that has the definitions because they'll be different >> metadata nodes). >> > > We will have two DIEs corresponding to the two definitions. > Unless one is a declaration and the other' > But when we actually refer to the definition via DIRef, we resolve to one > of the two definitions. > The member DIEs will be added to the single class that we resolve the > DIRef to. > > Manman > > > >> Since we didn't merge the member lists of the two >> definitions/declarations of 'foo', the child lis...

...ferent lists of members? I guess we'll produce two definitions of 'foo', > one in each CU that has the definitions because they'll be different > metadata nodes). > We will have two DIEs corresponding to the two definitions. But when we actually refer to the definition via DIRef, we resolve to one of the two definitions. The member DIEs will be added to the single class that we resolve the DIRef to. Manman > Since we didn't merge the member lists of the two definitions/declarations > of 'foo', the child list will be incomplete, but the context links i...

On Wed, Oct 16, 2013 at 10:54 AM, Manman Ren <manman.ren at gmail.com> wrote: > > > > On Tue, Oct 15, 2013 at 5:59 PM, David Blaikie <dblaikie at gmail.com> wrote: > >> >> In beginModule, we construct the CUs, but not all the DIEs that belong >>>>> to the CU. >>>>> In endFunction, we started to construct the scope DIEs. So in

...guess we'll produce two definitions of 'foo', >> one in each CU that has the definitions because they'll be different >> metadata nodes). >> > > We will have two DIEs corresponding to the two definitions. But when we > actually refer to the definition via DIRef, we resolve to one of the two > definitions. > The member DIEs will be added to the single class that we resolve the > DIRef to. > > Manman > > > >> Since we didn't merge the member lists of the two >> definitions/declarations of 'foo', the child lis...