================
@@ -6277,6 +6277,21 @@ RValue CodeGenFunction::EmitCall(const CGFunctionInfo
&CallInfo,
pushDestroy(QualType::DK_nontrivial_c_struct, Ret.getAggregateAddress(),
RetTy);
+ if (CalleeDecl) {
+ // Generate function declaration DISuprogram in order to be used
+ // in debug info about call sites.
+ if (CGDebugInfo *DI = getDebugInfo()) {
+ CodeGenFunction CalleeCGF(CGM);
----------------
jryans wrote:
I am definitely not a Clang code gen expert, so I tried to sort how to get the
`CodeGenFunction` by looking around the codebase.
>From looking around at other usages, it seems to me that new instances of
>`CodeGenFunction` are created on-demand like this to hold per-function code
>gen state when emitting constructors, blocks, and other more specialised
>functions (e.g. `ItaniumCXXABI::getOrCreateVirtualFunctionPointerThunk`).
>There are also some code gen AST visitors that hold a `CodeGenFunction` as
>they walk through expressions to emit, but I don't see how to make use of that
>here.
Constructing a `CodeGenFunction` sets up some pointers to a code gen builder,
debug info state, etc. I think it's okay to create one for the callee like
this, but again I am not an expert here.
The `CurGD` member of `CodeGenFunction` is used several functions called by
`CodeGenFunction::BuildFunctionArgList`. This only happens for various
`CXX*Decl` types, which is why the previous code didn't need to consider this.
Instead of creating a new `CodeGenFunction`, we _could_ temporarily change
`this->CurGD` to point at the callee, and then reset it back... I just didn't
see that pattern in use elsewhere, so I wasn't sure if it might confuse /
violate some constraint.
https://github.com/llvm/llvm-project/pull/166202
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
