jmorse wrote: > Yeah, seems problematic if the DWARF for a devirtualized or non-virtual call > (derived->Base::func() for instance) is indistinguishable from a virtual > call. Is that what's being proposed?
The interpretation I've been taking here is that we're providing more information where there was an absence of it, rather than changing a meaning. As far as I'm aware, we haven't been distinguishing virtual/non-virtual call sites in the past, just not recording extra information about indirect calls. (85% confidence here -- I think we've been recording "the call target is this register" in call-site info, but nothing more?). This patch would be providing new information that's narrowly true about the source code, following the example that Orlando has pulled out, the source-code _is_ a call to CBase::foo, but it also happens to be indirect due to it being a virtual call. I suppose my question is -- have consumers really been using the absence of a subprogram reference as a proxy for "this is a virtual call", or can we get away with not adding another attribute? If there's a serious risk that consumers are doing that, an attribute is fine; presumably in the number space we should place it immediately after DW_AT_LLVM_alloc_type? https://github.com/llvm/llvm-project/pull/167666 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
