[llvm-dev] Propagation of debug information for variable into basic blocks.

[Daniel Berlin via llvm-dev]

On Wed, Sep 21, 2016 at 12:29 PM, Keith Walker via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Adrian,
>
>
>
> I am currently investigating issues where variables that one would expect
> to be available in a debugger are not in code that is compiled at
> optimisations other than –O0
>
>
>
> The main problem appears to be with the LiveDebugValues::join() method
> because it does not allow variables to be propagated into blocks unless all
> predecessor blocks have an Outgoing Location for that variable.
>
>
>
> As a simple example in the C code:
>
>
>
> int func2( int);
>
> void func(int a) {
>
>         int b = func2(10);
>
>         for(int i = 1; i < a; i++) {
>
>                 func2(i+b);
>
>         }
>
> }
>
>
>
> One would reasonable expect when stopped within the body of the for loop
> that you could access the variable b in a debugger (especially as it is
> actually referenced in the loop).
>
>
>
> Unfortunately this is often not the case.   I believe that this is due to
> the requirement stated in the descriptive comment of
> LiveDebugValues::join() which states:
>
>   “if the same source variable in all the predecessors of @MBB reside in
> the same location.”
>
>
>
> In our simple example we end up with a series of blocks like
>
>
>
>   BB#0   Initial-block         Predecessor:
>                 Successor: BB#2
>
>
>
>   BB#1  for-body                Predecessor: BB#2
> Successor: BB#2
>
>
>
>   BB#2  for-condition       Predecessor: BB#0 BB#1
> Successor: BB#1 BB#3
>
>
>
>   BB#3  after-for                Predecessor:
> BB#2                          Successor :
>
>
>
> Now b is initially defined to be an “Outgoing Location” to BB#0,  but it
> isn’t imported into BB#2 because it is not defined as an “Outgoing
> Location” for both predecessor blocks BB#0 and BB#1.
>
>
>
> So the outcome is that the variable b is not available in the debugging
> information while in BB#2 (or BB#1).
>
>
>
> Now changing the algorithm in LiveDebugValues::join() to include all
> Outgoing Locations from predecessor blocks appears to significantly improve
> the visibility of variables in such cases.    However I am worried that
> doing this possibly propagates the variables more than intended ... or
> maybe it is the right thing to do.
>


GCC uses union of predecessor outs.

This looks to be trying to convert it to a lattice problem, but isn't
handling of the lattice looks a little odd.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160921/125043d4/attachment.html>