<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 11, 2016 at 6:55 PM, Chandler Carruth via llvm-commits <span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">chandlerc added inline comments.<br>
<span class=""><br>
================<br>
Comment at: lib/CodeGen/BranchFolding.cpp:656<br>
@@ +655,3 @@<br>
+  // duplicated.<br>
+  if (!AfterPlacement)<br>
+    if (SuccBB && MBB1 != PredBB && MBB2 != PredBB &&<br>
----------------<br>
</span><span class="">davidxl wrote:<br>
> iteratee wrote:<br>
> > Discussed this with chandlerc. He thinks that passing around the list of blocks that were tail-duplicated too tightly couples the passes, and that we should strive to have non-overlap. He suggested that a list of blocks that were duplicated might be a good debug measure to make sure they aren't being re-merged.<br>
> ><br>
> > Overall I agree with him, and I made a change so there shouldn't be any overlap.<br>
> > Do you want to see the set as a debugging measure?<br>
> I don't agree. Without making it explicit, the the pass coupling does not disappear -- it is still there but in a more implicit but hard to maintain way.<br>
><br>
> For instance, can we guarantee this still work when TailMerger and TailDuplicator uses non-default size thresholds?<br>
</span>My thought was specifically that we should enforce an invariant that these are defined in a non-overlapping way, *and* check it in asserts builds precisely so that things like non-default size thresholds work in a sane way.<br>
<br></blockquote><div><br></div><div>The problem is that the implementation maintains the non-overlapping by making assumption about the size limit (the default setting), so when non-default size is used, the assertion will likely to fire off.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As long as there is the potential for overlap, we have the problem (IMO) that the innards of tail dup or tail merge can do things that user programs cannot. I would much prefer that we have a set of rules that are sufficiently precise and enforced that one pass doesn't have to have a back-channel to communicate to the other pass.<br>
<br></blockquote><div><br></div><div>Passing a 'filter' is actually the exact mechanism IMO to hide pass implementation details from one another. Is there a better way? Making any assumption about how tailDup is done in tailMerger is the wrong direction to take.</div><div><br></div><div>David</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
But I do agree that it is important that this is actually a guaranteed property and one we check that we don't violate.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<a href="http://reviews.llvm.org/D18226" rel="noreferrer" target="_blank">http://reviews.llvm.org/D18226</a><br>
<br>
<br>
<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div><br></div></div>