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

[Adrian Prantl via llvm-dev]

[+ some folks more knowledgable about the Machine layer than me.]

> On Feb 12, 2019, at 5:07 AM, Nikola Prica <nikola.prica at rt-rk.com> wrote:
> 
> 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.

So you're saying that in late MIR, the target-specific MachineInstructions don't have enough generic meta information to understand where data was copied/loaded from in a target-independent way? Would it be easier in earlier pre-regalloc MIR, or does that have the same problem because the instructions are already target-specific?

> 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                       ->
> 

I'm not sure I can follow this example (yet). Is this about creating a call site parameter for an argument of the call to foo, or is it meant to illustrate that the call to foo() makes it hard to write a backwards analysis for inserting a call site parameter for a call site below the call to foo()?

> This is the case from ‘VirtRegMap’ pass, but I think it can happen
> elsewhere.

As I'm not super familiar with the various MIR passes: Is VirtRegMap the pass inserting the vreg copy from $rsi here? Does it do something else?

>  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.

What information exactly would you need about foo's implementation that you cannot get from just knowing the calling convention?

> 
> 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.

My main motivation for this discussion is to minimize the added complexity of the feature. For example, if we figure out that we can get by without introducing new IR constructs (that optimization authors would need to be taught about, that would need to be supported in all three instruction selectors) and can get by with only adding new MIR instructions, that would be a win. However, if we can prove that deferring the analysis to a later stage would result in inferior quality then the extra maintenance burden of new IR constructs may be the right tradeoff.

Thanks for taking the time to walk me through your thought process.
-- adrian
> 
> 
> Thanks,
> 
> Nikola