[cfe-dev] RFC: Remove uninteresting debug locations at -O0

[David Blaikie via cfe-dev]

On Wed, Apr 29, 2020 at 2:52 PM Reid Kleckner <rnk at google.com> wrote:

> Sure, I can try to elaborate, but I am assuming a bit about what the users
> desired stepping behavior is. I am assuming in this case that the user is
> doing the equivalent of `s` or `n` in gdb, and they want to get from one
> semicolon to the next. If that is not the case, if the user wants the
> debugger to stop at the location of both getFoo() calls in your example, my
> suggestion isn't helpful.
>
> However, since the last dev meeting, I have been thinking about having IR
> intrinsics that mark the IR position where a statement begins. The
> intrinsic would carry a source location. The next instruction emitted with
> that source location would carry the DWARF is_stmt line table flag.
>
> Making this idea work with optimizations is harder, since the instructions
> that make up a statement may all be removed or hoisted. To make this work,
> we would have to establish which instructions properly belong to the
> statement. This could be done by adding a level to the DIScope hierarchy.
> The statement markers would remain in place, and code motion would happen
> around them.
>

In this case there would be no intrinsic, just a new kind of "statement"
DIScope? yeah, that's the best idea I've had/heard of/discussed for
statement grouping so far. Certainly seems imminently prototype-able & then
get a sense for just how expensive scoping everything like that would be.


> Late in the codegen pipeline, the first instruction belonging to the most
> recently activated statement will be emitted with the is_stmt flag.
>
> On Wed, Apr 29, 2020 at 9:36 AM Adrian Prantl <aprantl at apple.com> wrote:
>
>> Thanks to all of you for sharing your perspective! You all brought up
>> important aspects that I hadn't considered. The argument that really
>> clicked for me was Pavel's that you might want to change the value before
>> the load happens.
>>
>> One of my worries here is that what I called "less interesting" locations
>> might delete more interesting ones when instructions and their locations
>> are merged. But if we indeed consider the stack slot loads to be
>> interesting then that is really the best we can do. After all, storing more
>> than source location per instruction would be a UI design nightmare for a
>> debugger.
>>
>
Actually I'd kind of love this - I think it'd be really great to describe
source ranges instead of source locations - probably super size costly
though (& intermediate compiler memory usage, etc). Being able to describe
nesting, etc - the same way Clang does with expression/subexpression
highlighting I think would be wonderful - imagine if every instruction
weren't just attributed to one location, but to a source range with a
preferred location (instead of just pointing to the "+" for an add, be able
to highlight the LHS and RHS of that plus expression, etc).


>
>>
>> Reid, I would like to learn more about what you mean by statement
>> tracking. I'm thinking of a statements as the expressions separated by
>> semicolons, but since my whole example was a single statement I'm assuming
>> you have something more fine-grained in mind. Perhaps you can post an
>> example to illustrate what you have in mind?
>>
>>
>> thanks!
>> -- adrian
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200429/6f755b5d/attachment.html>