[PATCH] D18226: Codegen: Tail-duplicate during placement.

Chandler Carruth via llvm-commits llvm-commits at lists.llvm.org
Mon Jul 11 18:55:19 PDT 2016


chandlerc added inline comments.

================
Comment at: lib/CodeGen/BranchFolding.cpp:656
@@ +655,3 @@
+  // duplicated.
+  if (!AfterPlacement)
+    if (SuccBB && MBB1 != PredBB && MBB2 != PredBB &&
----------------
davidxl wrote:
> iteratee wrote:
> > 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.
> > 
> > Overall I agree with him, and I made a change so there shouldn't be any overlap.
> > Do you want to see the set as a debugging measure?
> 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.   
> 
> For instance, can we guarantee this still work when TailMerger and TailDuplicator uses non-default size thresholds?
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.

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.

But I do agree that it is important that this is actually a guaranteed property and one we check that we don't violate.


http://reviews.llvm.org/D18226





More information about the llvm-commits mailing list