[llvm-dev] [RFC] Moving llvm.dbg.value out of the instruction stream

[Chris Lattner via llvm-dev]

> On Oct 24, 2018, at 11:19 AM, Chris Lattner <clattner at nondot.org> wrote:
> 
>> On Oct 22, 2018, at 6:43 PM, Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>> Here are the numbers I got from my patch:
>> 
>> 160402 codegenprepare - Total number of llvm.dbg.* instructions
>> 296080 codegenprepare - Total number of instructions
>> 
>> So, 54% of all instructions are dbg.(value|declare) instructions today! Moving them out of the main BB ilist would speed up BB iteration by 2x. That's not necessarily where we spend our time. I happen to already know that this test case does a lot of BB scanning (PR38829), so I know it will help this test case, but it may not matter if we make local dominance not scan.
> 
> Whoa.

One other random thought: how many of these llvm.dbg.* are directly adjacent to each other?  It would be very simple to extend llvm.dbg.value/declare to be a *list* of declarations.  If many of these are next to each other (or are close enough, e.g. simple casts between them) then you could keep the per-instruction design and get the vast majority of the win.  This would be super incremental.

-Chris

> 
>> dbg.value is meant to associate an SSA value with a label. My basic idea is that it's better to attach a label to the instruction it precedes rather than creating a separate instruction. However, a label should stay behind if the instruction it precedes moves. For example, Instruction::moveAfter/moveBefore should implicitly reattach their variable tracking info to the next instruction. While working on https://reviews.llvm.org/D51664 <https://reviews.llvm.org/D51664>, I realized it would be pretty easy to use the ilist callbacks currently used for symbol table updating to implement this.
> 
> To point out something you already know :-), moveFirst and friends are just helper functions for more general ilist manipulation mechanisms that move chunks of instructions.
> 
> -Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181024/8f3709f1/attachment.html>