<div dir="ltr">On 27 July 2013 09:11, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div style="word-wrap:break-word"><div class="im">On Jul 26, 2013, at 6:24 PM, Nick Lewycky <<a href="mailto:nicholas@mxc.ca" target="_blank">nicholas@mxc.ca</a>> wrote:<br></div><div><div class="im"><blockquote type="cite">

<div style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">URL:<span> </span><a href="http://llvm.org/viewvc/llvm-project?rev=187283&view=rev" target="_blank">http://llvm.org/viewvc/llvm-project?rev=187283&view=rev</a><br>

Log:<br>Reimplement isPotentiallyReachable to make nocapture deduction much stronger.<br>Adds unit tests for it too.<br><br>Split BasicBlockUtils into an analysis-half and a transforms-half, and put the<br>analysis bits into a new Analysis/CFG.{h,cpp}. Promote isPotentiallyReachable<br>

into llvm::isPotentiallyReachable and move it into Analysis/CFG.<br></div></blockquote><div dir="auto"><br></div></div>Random unit test question for you:</div><div dir="auto"><div class="im"><br><blockquote type="cite"><div style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">

+TEST_F(IsPotentiallyReachableTest, SameBlockNoPath) {<br>+  ParseAssembly(<br>+      "define void @test() {\n"<br>+      "entry:\n"<br>+      "  bitcast i8 undef to i8\n"<br>+      "  %B = bitcast i8 undef to i8\n"<br>

+      "  bitcast i8 undef to i8\n"<br>+      "  bitcast i8 undef to i8\n"<br>+      "  %A = bitcast i8 undef to i8\n"<br>+      "  ret void\n"<br>+      "}\n");<br>+  ExpectPath(false);<br>

+}<br></div></blockquote><div dir="auto"><br></div></div><div dir="auto">I understand the value of unit tests for stuff like this, but dumping swaths of LLVM IR into them seems really weird to me.  Why not just express these tests in terms of the benefit, i.e., cases that make nocapture inference work better?  Then they can be written as .ll files like most of our testsuite.</div>

</div></div></blockquote><div><br></div><div>I wish I could test just the algorithm in the abstract. If I could do it with no IR at all I would, but I need to test the interaction with DominatorTree and LoopInfo, so I don't have a choice there. The test must have IR.</div>

<div><br></div><div>The effect that it has on nocapture is a bit distant, it's not quite as bad as writing a test for SmallVector by looking at its impact on the IR, but it's down that vein. Such a test would be fragile, first of all. Secondly, it's not easy to write IR which would trigger the exact isPotentiallyReachable calls that I want. Third, I want to test the four combinations of whether domtree and loopinfo are present, and the only caller now always provides domtree and never loopinfo. (I realize there's only one caller in-tree, but I have written others and have just been waiting for this to get in so that I can land them. Those will come with matching IR tests.)</div>

<div><br></div><div>Ultimately, if I just wrote it in terms of nocapture tests, I wouldn't be convinced of its correctness.</div><div><br></div><div>Nick</div><div><br></div></div></div></div>