<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Oct 24, 2018, at 11:19 AM, Chris Lattner <<a href="mailto:clattner@nondot.org" class="">clattner@nondot.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class="">On Oct 22, 2018, at 6:43 PM, Reid Kleckner via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><div class="">Here are the numbers I got from my patch:</div><div class=""><br class=""></div><div class="">160402 codegenprepare - Total number of llvm.dbg.* instructions</div><div class="">296080 codegenprepare - Total number of instructions</div><div class=""><br class=""></div><div class="">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.</div></div></div></div></blockquote><div class=""><br class=""></div>Whoa.</div></div></div></blockquote><div><br class=""></div><div>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.</div><div><br class=""></div><div>-Chris</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><div class="">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 <a href="https://reviews.llvm.org/D51664" class="">https://reviews.llvm.org/D51664</a>, I realized it would be pretty easy to use the ilist callbacks currently used for symbol table updating to implement this.</div></div></div></div></blockquote><div class=""><br class=""></div>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.</div><div class=""><br class=""></div>-Chris</div></div></blockquote></div><br class=""></body></html>