<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 6, 2015, at 1:24 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com" class="">dblaikie@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><br class="Apple-interchange-newline"><br style="font-family: Menlo-Regular; font-size: 11px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_quote" style="font-family: Menlo-Regular; font-size: 11px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On Fri, Feb 6, 2015 at 1:20 PM, Duncan P. N. Exon Smith<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:dexonsmith@apple.com" target="_blank" class="">dexonsmith@apple.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><span class=""><br class="">> On 2015-Feb-06, at 10:36, David Blaikie <<a href="mailto:dblaikie@gmail.com" class="">dblaikie@gmail.com</a>> wrote:<br class="">><br class="">><br class="">><br class="">> On Wed, Feb 4, 2015 at 4:17 PM, Adrian Prantl <<a href="mailto:aprantl@apple.com" class="">aprantl@apple.com</a>> wrote:<br class="">><br class="">>> On Feb 4, 2015, at 3:53 PM, Frédéric Riss <<a href="mailto:friss@apple.com" class="">friss@apple.com</a>> wrote:<br class="">>><br class="">>><br class="">>>> On Feb 4, 2015, at 3:46 PM, Duncan P. N. Exon Smith <<a href="mailto:dexonsmith@apple.com" class="">dexonsmith@apple.com</a>> wrote:<br class="">>>><br class="">>>><br class="">>>>> On 2015-Feb-04, at 15:37, Frédéric Riss <<a href="mailto:friss@apple.com" class="">friss@apple.com</a>> wrote:<br class="">>>>><br class="">>>>>>><br class="">>>>>>> - The word 'context' is overloaded: `MDNode::getContext()` already<br class="">>>>>>> exists, and returns an `LLVMContext&`; `DIDescriptor` uses 'context'<br class="">>>>>>> to mean "the node that this one is defined inside". I chose the<br class="">>>>>>> word 'parent' instead of 'context' here. Is this word okay? If<br class="">>>>>>> not, what about 'scope'? This will be reflected in the assembly<br class="">>>>>>> changes to come (I'd like the C++ names to match the assembly names,<br class="">>>>>>> although technically it's not necessary).<br class="">>>>>>><br class="">>>>>>> I'd /probably/ go with scope (we already have scope in the MDLocations, so that seems consistent), but fairly on-the-fence.<br class="">>>>>>><br class="">>>>>><br class="">>>>>> Weirdly, I didn't even notice that :). In that case I like 'scope'<br class="">>>>>> better too. I'll update to that before commit.<br class="">>>>><br class="">>>>> Seems most natural. Can the futur getScope() return something that doesn’t derive from MDScope?<br class="">>>><br class="">>>> I don't think so.<br class="">>><br class="">>> That was my impression also, and it makes it even more appropriate IMHO.<br class="">>><br class="">><br class="">> Just a few general remarks to throw into the discussion:<br class="">><br class="">> - Would it make sense to use something like tablegen to generate the repetitive parts? I’m slightly worried about copy&paste bugs, moderately worried about refactoring it in the future.<br class="">><br class=""></span>> <classllvm_1_1DIScope__inherit__graph.png><br class=""><span class="">><br class="">> As for scopes, there are several things that bug me about the current class hierarchy that we could fix now:<br class="">> - DIFile should not be a scope (the concept of files is IMO orthogonal to scoping and there is always something more appropriate to put a node into: compile unit, module, namespace)<br class="">><br class="">> IIRC we do this when # line directives change the file-name part-way through. But I could be wrong... only vague idea.<br class="">><br class="">> - DIBasicType should not be scope<br class="">><br class="">> Part of this is the ability to treat all types the same - multiple inheritance might be an alternative, but without that we want to treat all types equally in some codepaths, but then only some types are valid scopes, etc. - so there's a few different axes on which we want to refer to these things. It's tricky. But certainly worth thinking about.<br class=""><br class=""></span>LLVM-style RTTI doesn't handle multiple inheritance, which restricts<br class="">us somewhat here.<br class=""></blockquote><div class=""><br class="">*nod* I seemed to recall something like that<br class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;">I imagine having a hierarchy like:<br class=""><br class=""> <span class="Apple-converted-space"> </span>DIScopeBase<br class=""> -> DIScope<br class=""> -> DINamespace<br class=""> -> DISubprogram<br class=""> -> DIType<br class=""> -> DIBasicType<br class=""> -> DIDerivedType<br class=""> -> DITypeScope<br class=""> -> DICompositeType<br class=""><br class="">would get us most of the way there.<br class=""><br class="">Pointers can be `DIScopeBase`. Call-sites that care about scopes<br class="">can check:<br class=""><br class=""> <span class="Apple-converted-space"> </span>assert(isa<DIScope>(N) || isa<DITypeScope>(N));<br class=""></blockquote><div class=""><br class="">Yep, if we're willing to pay the cost of having scopes not have a common ancestor to use. That might be the right tradeoff, I'm not sure.<br class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;">(We can add `DIScopeBase::isValidScope()` or something to do this.)<br class=""><br class="">Or maybe we don't even need a `DIScopeBase`.<br class=""></blockquote><div class=""><br class="">Yeah, if we go that way I don't think DIScopeBase would add anything, but not 100% sure.<br class=""></div></div></div></blockquote><div><br class=""></div><div>When I first discovered the type hierarchy, the every-type-is-a-scope thing got me a bit perplexed. I really think we should get rid of it. Would it be possible to have the Composite types point to a real scope instead of being one?</div><div><br class=""></div><div>Fred</div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_quote" style="font-family: Menlo-Regular; font-size: 11px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div class="HOEnZb"><div class="h5"><br class="">><br class="">> - It’s questionable whether a DICompositetype should be a DIDerivedType<br class="">> - A DISubroutineType should be neither a DIDerivedType nor DIScope<br class="">> - Using DIDerivedTypes for CV qualifiers is a bit wasteful but it does map nicely to DWARF<br class="">><br class="">> otherwise, thanks for doing this!<br class="">> -- adrian</div></div></blockquote></div></div></blockquote></div><br class=""></body></html>