search for: direfs

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

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

+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 within is different in the two TUs -

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

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

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

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

On Wed, Oct 16, 2013 at 11:54 AM, Manman Ren <manman.ren at gmail.com> wrote: > > > > On Wed, Oct 16, 2013 at 11:10 AM, David Blaikie <dblaikie at gmail.com>wrote: > >> >> >> >> On Wed, Oct 16, 2013 at 10:54 AM, Manman Ren <manman.ren at gmail.com>wrote: >> >>> >>> >>> >>> On Tue, Oct 15, 2013 at

On Wed, Oct 16, 2013 at 11:10 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > > 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

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

There are a few places where we break the assumption: 1> formal_parameter constructed in DwarfDebug when adding attribute type we call SPCU->addType(Arg, ATy), where Arg does not belong to SPCU. 2> inlined_subroutine constructed in DwarfDebug when adding attribute abstract_origin The inlined_subroutine does not belong to the CU we call addDIEEntry on. We create the children