probinson added a comment.
In D68117#1710295 <https://reviews.llvm.org/D68117#1710295>, @dblaikie wrote:
> I think the existing feature's perhaps a bit misspecified - because where you
> put the DEFAULTED_{in_class,out_of_class} would communicate that without
> needing the two values - if you put it on an out of line function definition,
> it's defaulted out of line, if you put it on the in-class declaration then
> it's defaulted inline.
>
> But spec'd the way it is, if we want to implement this at all/if there's some
> actual user need (admittedly the noreturn attribute has gone in recently
> without a discussion of usage... so I'm not the only gatekeeper here & other
> people have other opinions, and that's OK - if someone (@probinson @aprantl
> etc) want to tell me I'm being unreasonable here & we should just put it in -
> it's only a bit here or there & not likely to make a huge difference to DWARF
> size & possibly enable some scenarios we haven't imagined yet and avoid the
> chicken-and-egg problem for the future implementer of such features, that's
> OK) - I'd essentially implement it that way. Put DEFAULTED_out_of_class on
> the member function definition DIE if it's defaulted there, and put
> DEFAULTED_in_class on the declaration DIE if it's defaulted there.
>
> And I'd probably only spend one bit of flags on this, if possible - "not
> defaulted (0/assumed for all subprograms) or defaulted (1)" and translate it
> into one of the two values (in_class or out_of_class) in the backend based on
> which subprogram DIE it's attached to.
That seems reasonable too. Of course if we're already spending a bit on
Deleted, and the same subprogram can't be both Deleted and Defaulted, it costs
no extra DISP bits to represent the 4 cases (defaulted-in-class,
defaulted-out-of-class, deleted, none-of-the-above).
@SouraVX I would say we should never emit DEFAULTED_no. If the compiler
organized its internal data differently, and had a canned abbreviation for
ctors/dtors that included DW_AT_defaulted, then we'd need to fill that in; but
that's not how LLVM handles DWARF, it creates abbreviations on demand. So,
doing nothing in the none-of-the-above case would be best here.
(@dblaikie Aside regarding noreturn, the original DWARF proposal was for a
debugger wanting to know a given function will not return. As a flag, in the
DWARF it costs an extra abbrev entry but no space in .debug_info. Cheap enough
for me.)
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D68117/new/
https://reviews.llvm.org/D68117
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
