[llvm-dev] RFC: [DebugInfo] Improving Debug Information in LLVM to Recover Optimized-out Function Parameters (original) (raw)

Nikola Prica via llvm-dev llvm-dev at lists.llvm.org
Tue Feb 12 05:07:15 PST 2019

Hi,

I am one of the authors of this feature. On Phabricator, we agreed to take discussion whether encoding this in IR and threading it through the compiler or performing a late MIR analysis is the better approach.

Regarding late MIR pass approach, it would need to go back from call instruction by recognizing parameter's forwarding instructions and interpret them. We could interpret register moves, immediate moves and some of stack object loadings. There would be need to write interpretation of various architectures instructions. We were not positive about completeness of such recognition. However, such analysis might not be complete as current approach. It would not be able to produce ‘DW_OP_entry_values’ in ‘DW_TAG_call_site_value’ expression of call site parameter as a late pass.

As example think of callee function that forwards its argument in function call in entry block and never uses that argument again: %vreg = COPY $rsi; -> …. <no use of rsinorrsi nor %vreg> -> …<no use of rsinorrsi nor %vreg> rsi=COPYrsi = COPY rsi=COPYvreg; -> call foo call foo ->

This is the case from ‘VirtRegMap’ pass, but I think it can happen elsewhere. Recreation of this might be possible when function ‘foo’ is in current compilation module, but we are not sure if it is possible for external modules calls. In order to follow such cases we need DBG_CALLSITEPARAM that can track such situation.

Since after ISEL phase we have explicit pseudo COPY instructions that forward argument to another function frame, it came naturally to recognize such instructions at this stage. There we can say with 100% certainty that those instruction indeed forward function arguments.

Thanks,

Nikola

More information about the llvm-dev mailing list