dblaikie added a comment. In D70524#1772690 <https://reviews.llvm.org/D70524#1772690>, @probinson wrote:
> In D70524#1772117 <https://reviews.llvm.org/D70524#1772117>, @dblaikie wrote: > > > In D70524#1771709 <https://reviews.llvm.org/D70524#1771709>, @probinson > > wrote: > > > > > In D70524#1771522 <https://reviews.llvm.org/D70524#1771522>, @shafik > > > wrote: > > > > > > > @probinson I was reading the C++ "auto" return type > > > > <http://dwarfstd.org/ShowIssue.php?issue=131217.1> issue and I can't > > > > come up with a case where we don't have class descriptions across > > > > compilation units that are not consistent wrt to auto return type. Do > > > > you have a specific example? > > > > > > > > > The actual return type is known in a compile_unit where the method is > > > defined, and not known in other compile_units. If the non-defining > > > compile_units omit the return type, that means "void" not "auto". That > > > is, one compile unit says it returns "void" and another compile unit says > > > it returns something else. That is the inconsistency I meant. > > > > > > If we use unspecified_type instead of omitting the return type, then a > > > consumer knows that the method returns *something*, but it will have to > > > look elsewhere to determine what that is. > > > > > > Yeah, my argument was to omit the declarations of auto-returning functions > > entirely except in cases where their definition is available (either only > > when the definition is emitted, or whenever the definition's available so > > the deduced return type can be provided), same as a template instantiation. > > > > So the class would be missing the declaration of the function in cases > > where the definition isn't available - same as templates and implicit > > special members. > > > Understood. The class descriptions are inconsistent (in that sense) across > CUs. This means deduplication in the type-unit sense would be less > effective, but in the template-member and special-member cases there's really > not much to be done about it. This argument says that auto-return methods > aren't fundamentally different from those. I mean we could do something about them, to a degree - we could compute which special members are valid & emit them pre-emptively (though that'd be a bit tricky to do reliably, without unnecessarily instantiating any extra code, etc - but it's possible) & we could improve DWARF to have some description of templates. There still probably wouldn't be enough info to get overload resolution right, etc. >> (yeah, you could take this to its logical extreme and say we should treat >> all member functions this way - never produce a whole class definition >> enumerating all members - Eric and I have bandied that idea about as >> "classes as namespaces" more or less (the members in a class definition in >> one CU aren't necessarily the same as those in another, and a consumer would >> have to consider all of them together like it would have to for namespaces)) > > Heh. Implemented that locally years ago as a space-saving measure; > unreferenced methods are omitted. Our debugger internally merges the > different descriptions that it encounters. In the compiler, the trick is > that you don't actually know which methods to suppress until IRGen is > complete, so I had to invent a Suppressed flag on the DISubprogram, that > causes DwarfDebug to ignore it. Oh, I'd just implement it like the template/implicit special member - the DISubprograms are built as-needed/only referenced from the llvm::Function, they don't appear in the "members" list of the DICompositeType at all, and then DwarfDebug attaches any that make it to LLVM's CodeGen/need to be emitted then. If you comment out this call: https://github.com/llvm/llvm-project/blob/master/clang/lib/CodeGen/CGDebugInfo.cpp#L2296 you can probably get the behavior you want without any other changes? (tested that, and it reduced the dwarfdump debug_info dumped output from 3.5k lines to 1k lines) Perhaps we should implement this mode under -fno-standalone-debug (or something more aggressive) since "standalone" is one of the only places I can think of where having the full class definition would be handy - it'd make it clear that there is a specific function overload that can be called & the debugger could mangle the name and find the symbol in another TU that was built without debug info... not sure if any implement that, though. (that wouldn't be quite possible with an auto-returning function - you'd need to know the return type to figure out the calling ABI/handle the return value) >> & honestly it's going to be pretty uncommon that any of this comes up - >> people aren't likely to separate their auto-returning function declaration >> from its definition. It'd be awkward to read code like that. > > If it's a class method, which is the only case of interest (otherwise the > unused declaration is suppressed anyway), the auto-return method is in the > class declaration and all users of the header will have to see it. Most > likely it would be a private method and used only in the implementation > module, but still. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D70524/new/ https://reviews.llvm.org/D70524 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
