search for: decl_file

...ss range in the CU the function was originally in - but the >>> subprogram DIE ends up in some other CU that doesn't include that >>> address range) >> >> I think you just convinced me to save this for later and clone a namespace for every compile unit instead. The decl_file/decl_line will have to identical for all CUs though (and come from the module linked in first). > > OK - so we'll put one namespace in the metadata and just use that for > each CU? Should be easy enough. > > One issue: what keeps the namespace metadata nodes live? Where do we &gt...

...uld we end up with > the address range in the CU the function was originally in - but the > subprogram DIE ends up in some other CU that doesn't include that > address range) I think you just convinced me to save this for later and clone a namespace for every compile unit instead. The decl_file/decl_line will have to identical for all CUs though (and come from the module linked in first). thanks! adrian > > - David > >> -- adrian >> >>> On Jun 24, 2014, at 4:39 PM, Adrian Prantl <aprantl at apple.com> wrote: >>> >>> >>>...

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

...ata !{i32 786434, metadata !5, metadata !18, metadata !"Test<int>", 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? F...

I looked into this a little. My proposal is this: - extend DINamespace with an extra UniqueID filed (analogous to DICompositeType) - add an extra case to DIScope::getRef() - Let CGDebugInfo create a mangled name for each namespace to use as UID -> the UID of the anonymous namespace is null. For example: namespace a { namespace b {} } -> “_ZN1a", “_ZN1a1b" !0 = [compile unit]