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

[Nikola Prica via llvm-dev]

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 $rsi nor %vreg>  ->   …<no use of $rsi nor %vreg>
  $rsi = COPY $vreg;             ->   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