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

[Xinliang David Li via llvm-commits]

On Mon, Jul 11, 2016 at 6:55 PM, Chandler Carruth via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> 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.
>
>
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.


> 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.
>
>
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.

David




> 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
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160711/37c67401/attachment.html>