[PATCH] D94347: [WebAssembly] locals can now be indirect in DWARF

[Derek Schuff via Phabricator via llvm-commits]

dschuff added a comment.

I looked a little at DW_AT_calling_convention and it looks like clang does use it (e.g. DW_CC_pass_by_reference), even for dwarf 4, for e.g. nontrivially-copyable classes (see e.g. https://github.com/llvm/llvm-project/blob/master/clang/test/CodeGenCXX/debug-info-composite-cc.cpp). In this case though, a function that takes this value is also generated in the IR as a pointer rather than a byval.
In order to make this work we'd probably need to make the contract between a frontend that uses byval and the backend even more obscure (i.e. it would need to mark all the type infos for structs with this attribute in addition to making them passed byval). In other words since it's the backend that decides exactly how a byval IR parameter is passed it makes sense that the backend also sets the debug info accordingly. Assuming that's possible or reasonable, of course; that's why I was asking about what it would take to pass the information through to DwarfExpression::addWasmLocation.

> I can "slip in" a DW_OP_deref, but then the bool that indicates that this needs to happen needs to be passed through all the way from ExplicitLocals to the DWARF emitter, for which the likeliest storage is the TargetIndex like we are doing currently. So at least code-wise this solution would be less elegant, since now we're duplicating information at the end.

Yeah I guess to be more clear, that's basically what I had in mind; i.e. we'd still need to pass the information from ExplicitLocals to the dwarf emitter, and using the TargetIndex just as this CL does makes sense for that. the only difference would be that instead of encoding TI_LOCAL_INDIRECT directly into first argument of DW_OP_WASM_location, that the Dwarf writer would instead change the final argument of DW_AT_location to DW_OP_deref. That change is less elegant in the LLVM code but makes the standardized interface simpler.

> Do these ABIs need to be adhered to for static functions calling each other internally to a compilation unit (in -O2)?

No, the midlevel optimizer can and does change the calling convention (including dropping unused arguments) for internal functions. This is especially powerful when using LTO. In order to have correct debug info it would need to change the formal parameter information of the function according to whatever optimization it does (i don't know if it actually does that; but presumably that might be easier than changing the type info for the struct type, which then would no longer match other uses of that type?)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D94347/new/

https://reviews.llvm.org/D94347