<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Thanks for the suggestions Vedant. Synthetic debug info is an interesting idea that sounds worthwhile. Could this be implemented as a “wrapper” pass that automatically decorates debug info before and after a specific pass run in opt (or pipeline of passes)? It might be useful to be able to easily enable this for a wide range of tests without having to manually modify each run line, perhaps as an environment variable/build time flag.<div class=""><br class=""></div><div class="">Cheers,</div><div class="">Amara<br class=""><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 27, 2017, at 6:18 PM, Vedant Kumar <<a href="mailto:vsk@apple.com" class="">vsk@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: SFHello-Regular; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><br class="Apple-interchange-newline">On Nov 17, 2017, at 4:41 PM, Gerolf Hoflehner <<a href="mailto:ghoflehner@apple.com" class="">ghoflehner@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class="Apple-interchange-newline"><br class=""><blockquote type="cite" class=""><div class="">On Nov 13, 2017, at 11:53 AM, Vedant Kumar via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span class="" style="font-family: Helvetica; font-size: 18px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">Hi Amara,</span><div class="" style="font-family: Helvetica; font-size: 18px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 18px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""><blockquote type="cite" class=""><div class="">On Nov 10, 2017, at 9:12 AM, Amara Emerson via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space;">Hi everyone,<div class=""><br class=""></div><div class="">This RFC concerns the design and architecture of a generic machine instruction combiner/optimizer framework to be developed as part of the GISel pipeline. As we transition from correctness and reducing the fallback rate to SelectionDAG at -O0, we’re now starting to think about using GlobalISel with optimizations enabled. There are obviously many parts to this story as optimizations happen at various stages of the codegen pipeline. The focus of this RFC is the replacement of the equivalent of the DAGCombiner in SDAG land. Despite the focus on the DAGCombiner, since there aren’t perfect 1-1 mappings between SDAG and GlobalISel components, this may also include features that are currently implemented as part of the target lowerings, and tablegen isel patterns. As we’re starting from a blank slate, we have an opportunity here to think about what we might need from such a framework without the legacy cruft (although we still have the high performance bar to meet).</div><div class=""><br class=""></div><div class="">I want to poll the community about what future requirements we have for the GISel G_MI optimizer/combiner. The following are the general requirements we have so far:</div><div class=""><br class=""></div><div class=""><ol class="MailOutline"><li class="">It should have at least equivalent, but hopefully better runtime/compile time trade off than the DAGCombiner.</li><li class="">There needs to be flexibility in the design to allow targets to run subsets of the overall optimizer. For example, some targets may want to avoid trying to run certain types of optimizations like vector or FP combines if they’re either not applicable, or not worth the compile time.</li><li class="">Have a reasonably concise way to write most optimizations. Hand written C++ will always be an option, but there’s value in having easy to read and reason about descriptions of transforms.</li></ol><div class=""><br class=""></div></div><div class="">These requirements aren’t set in stone nor complete, but using them as a starting point: a single monolithic “Generic MI combiner” component doesn’t look like the right approach. Our current thinking is that, like we’ve done with the Legalizer, the specific mechanics of the actual optimization should be separated into it’s own unit. This would allow the combines to be re-used at different stages of the pipeline according to target needs. Using the current situation with instcombine as an example, there is no way to explicitly pick and choose a specific subset of IC, it’s only available as a whole pass with all the costs that entails.</div><div class=""><br class=""></div><div class="">The reasoning behind req 3 is that there may be compile time savings available if we can describe in a declarative style the combines we want to do, like it’s currently possible with tablegen patterns. This hasn’t been proven out yet, but consider an alternative where we use the machine instruction equivalent of the IR/PatternMatch tooling which allows easy and expressive matching of IR sub-trees. A concern I have with using that as the main approach to writing combines is that it’s easy to add new matchers in an routine which re-computes information that’s previously been computed in previous match() attempts. This form of back-tracking might be avoided if we can reason about a group of combines together automatically (or perhaps we could add caching capabilities to PatternMatch).</div><div class=""><br class=""></div><div class="">What would everyone else like to see from this?</div></div></div></blockquote><div class=""><br class=""></div><div class="">It would be great to provide first-class support for maintaining debug value information as a part of the new combine framework.</div><div class=""><br class=""></div><div class="">With SelectionDAG, we don't have a systematic way of preserving debug locations and values across combines. This is a source of optimized debugging bugs. If, as a part of the new framework, we could concisely express that a RAUW-style combine simply transfers debug values from A to B, we might define away some of these bugs [1].</div><div class=""><br class=""></div><div class="">Adrian put in place some infrastructure to do this in SelectionDAG (r317825). However, auditing/fixing debug value transfer issues in hand-written combines is time-consuming. I think it should be a goal of the new framework to make this a bit easier.</div></div></div></div></blockquote><div class=""><br class=""></div>+1 </div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Do you and/or Adrian also have thought on testing debug values? Verification and testing strategies should/could be part of the design also.<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">I have two ideas on how to approach testing.</div><div class=""><br class=""></div><div class="">1) Recycle existing targeted lit tests to test debug info preservation.</div><div class=""><br class=""></div><div class="">Consider a targeted lit test which look like this:</div><div class="">RUN: opt -S<span class="Apple-converted-space"> </span><b class="">-loop-reduce</b><span class="Apple-converted-space"> </span>addrec-gep.ll -o - | FileCheck %s</div><div class=""><br class=""></div><div class="">We can repurpose this test by attaching synthetic debug information to the IR, and then checking how much of it survives LSR. I prototyped this idea for IR-level tests over the break. Adding a debug info test looks like this:</div><div class="">RUN: opt -S<span class="Apple-converted-space"> </span><b class="">-debugify -loop-reduce -check-debugify</b><span class="Apple-converted-space"> </span>addrec-gep.ll -o - | FileCheck ...</div><div class=""><br class=""></div><div class="">The check-debugify pass can determine which DILocations and DIVariables went missing:</div><div class=""><br class=""></div><span class=""></span></div><blockquote type="cite" class="" style="font-family: SFHello-Regular; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;"><div class=""><span class="">CheckDebugify: Instruction with empty DebugLoc -- %lsr.iv1 = bitcast double* %lsr.iv to i1*<br class="">CheckDebugify: Missing line 3<br class="">CheckDebugify: Missing line 4<br class="">...<br class="">CheckDebugify: Missing line 33</span></div></blockquote><div style="font-family: SFHello-Regular; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span class=""><br class=""></span></div><span class="" style="font-family: SFHello-Regular; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">This could be a handy way to create new targeted test cases at the IR/MIR level. Something like this would have helped triage issues like </span><a href="http://llvm.org/" class="" style="font-family: SFHello-Regular; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;">llvm.org/</a><span class="" style="font-family: SFHello-Regular; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">PR25630 as well.<br class=""></span><span class="" style="font-family: SFHello-Regular; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></span><div style="font-family: SFHello-Regular; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span class="">2) Assert that combines preserve debug info.</span></div><div style="font-family: SFHello-Regular; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span class=""><br class=""></span></div><div style="font-family: SFHello-Regular; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span class="">If there's an important API like "CombineTo(From, To)", it could be useful to assert that the To node has at least as much debug info as the From node. I'm experimenting with this in SelectionDAG (</span><a href="http://llvm.org/PR35338" class="">llvm.org/PR35338</a>). I don't yet know where these asserts belong, how strict they should be, or if they need exception lists for certain combines.</div><div style="font-family: SFHello-Regular; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: SFHello-Regular; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">---</div><div style="font-family: SFHello-Regular; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: SFHello-Regular; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">Adrian and others have thought about these issues much more, so take these ideas with a grain of salt :).</div><div style="font-family: SFHello-Regular; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: SFHello-Regular; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">thanks,</div><div style="font-family: SFHello-Regular; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">vedant</div><div style="font-family: SFHello-Regular; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span class=""><br class=""></span><span class=""><br class=""></span><blockquote type="cite" class=""><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite" class=""><div class=""><div class="" style="font-family: Helvetica; font-size: 18px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""><div class=""><br class=""></div><div class="">best,</div><div class="">vedant</div><div class=""><br class=""></div><div class="">[1] To pick one at random, the '(zext (zextload x)) -> (zext (truncate (zextload x)))' combine should transfer debug values from N to the new ExtLoad, and from N0 to the new (trunc ExtLoad), but currently doesn't.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space;"><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Amara</div></div>_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class=""></div></blockquote></div><br class=""></div><span class="" style="font-family: Helvetica; font-size: 18px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">_______________________________________________</span><br class="" style="font-family: Helvetica; font-size: 18px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-family: Helvetica; font-size: 18px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">LLVM Developers mailing list</span><br class="" style="font-family: Helvetica; font-size: 18px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><a href="mailto:llvm-dev@lists.llvm.org" class="" style="font-family: Helvetica; font-size: 18px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">llvm-dev@lists.llvm.org</a><br class="" style="font-family: Helvetica; font-size: 18px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" class="" style="font-family: Helvetica; font-size: 18px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a></div></blockquote></div></div></blockquote></div></div></blockquote></div><br class=""></div></div></body></html>