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

[Adrian Prantl via llvm-dev]

> On Feb 22, 2019, at 2:49 AM, Nikola Prica <nikola.prica at rt-rk.com> wrote:
> 
> Hi,
> 
> We have done some investigation. Please find my comment inlined bellow.
> 
>> 
>> On 14.02.2019. 20:20, Quentin Colombet wrote:
>>> Hi all,
>>> 
>>> As much as possible I would rather we avoid any kind of metadata in MIR
>>> to express the semantic of instructions.
>>> Instead I would prefer that each back provides a way to interpret what
>>> an instruction is doing. What I have in mind is something that would
>>> generalize what we do in the peephole optimizer for instance (look for
>>> isRegSequenceLike/getRegSequenceInputs and co.) or what we have for
>>> analyzing branches.
>>> One way we could do that and that was discussed in the past would be to
>>> describe each instruction in terms of the generic mir operations.
>>> 
>>> Ultimately we could get a lot of this semantic information automatically
>>> populated by TableGen using the ISel patterns, like dagger does
>>> (https://github.com/repzret/dagger).
>>>> Anyway, for the most part, I believe we could implement the
>>> “interpreter” for just a handful of instruction and get 90% of the
>>> information right.
>>> 
>> 

[...]

>>>> Here's a proposal for how we could proceed:
>>>> 1. Decide whether to add (a) DBG_CALLSITEPARAM vs. (b) augment MIR to
>>>> recognize LEA semantics and implement an analysis
>>>> 2. Land above MIR support for call site parameters
>>>> 3. if (a), land support for introducing DBG_CALLSITEPARAM either in
>>>> calling convention lowering or post-ISEL
>>>> 4. if that isn't good enough discuss whether IR call site parameters
>>>> are the best solution
>>>> 
>>>> let me know if that makes sense.
>>>> 
>>>> Thanks,
>>>> adrian
>>> 
> 
> 
> In order to use calling convention lowering at MIR pass level, for
> recognizing instructions that forward function arguments, we would need
> to implement calling convention interpreter. Only recognizing
> instructions and trying to see whether it is part of calling sequence,
> would not be enough. For example, we will not be able to properly handle
> cases when one 64bit argument is split on two 32bit registers. This
> could be handled if we know number and sizes of arguments of called
> function, but then we would end up calling similar process as one from
> ISEL phase. We can only know number and sizes of arguments for direct
> calls since we can find IR function declaration for it and extract such
> information. For indirect calls, we would not be able to perform such
> analysis since we cannot fetch function’s declaration. This means that
> we will not be able to support indirect calls (not without some trickery).
> 
> If everybody agrees with stated, this might be the technical reason to
> give up with MIR pass that would collect call site parameter debug info.
> If we are wrong with our analysis, please advise us. Otherwise, we can
> go with approach with introducing DBG_CALLSITEPARAM and producing it
> from ISEL phase (with dispatched IR part).
> 
> Thanks,
> Nikola

If we want to avoid adding new MIR metadata as Quentin suggests, it sounds like we have really two problems to solve here:

1. At the call site determine which registers / stack slots contain (source-level) function arguments. The really interesting case to handle here is that of a small struct whose elements are passed in registers, or a struct return value.

The information about the callee's function signature is only available at the IR level. If we can match up a call site in MIR with the call site in IR (not sure if that is generally possible) we could introduce new API that returns the calling convention's location for each source-level function argument. Having such an API would be good to have; LLDB for example would really like to know this, too.
That said, I would not want to loose the ability to model indirect function calls. In Swift, for example, indirect function calls are extremely common, as are virtual methods in C++.

2. Backwards-analyze a safe location (caller-saved register, stack slot, constant) for those function arguments.

This is where additional semantic information would be necessary.


Quentin, do you see a way of making (1) work without having the instruction selector lower function argument information into MIR as extra debug info metadata? I'm asking because if we have to add extra debug info metadata to deliver (1) anyway then we might as well use it instead of implementing an analysis for (2).

what do you think?
-- adrian