[PATCH] D32252: [GVN] Add phi-translate for scalarpre as a temporary solution

Wei Mi via llvm-commits llvm-commits at lists.llvm.org
Mon May 1 18:29:36 PDT 2017


On Wed, Apr 19, 2017 at 11:26 PM, Daniel Berlin via Phabricator
<reviews at reviews.llvm.org> wrote:
> dberlin added a comment.
>
>
>
>>> I suspect you will have issues with backedges with this approach. I'm pretty sure it will fail in some cases to fixpoint (but maybe gvn is not strong enough to make that happen)
>>>  At the very least, you don't want this to transform:
>>
>> There is code in performScalarPRE checking whether the predecessor is the same as current bb and giving up if it is true. I tried small testcase and it seemed fine. I will pay attention to it when exercise it with more tests.
>
> This code will only work for the trivialest of cases :)
>
> GVN computes the RPO ordering.
> The easiest way to detect backedges is to densemap that.
> An edge x->y is a backedge if RPO[x] >= RPO[y]
>
> (This is because in a postorder traversal, you are guaranteed it will find the edges that lead to a block, before that block, since it will process all children to completion first
> So in a PO, PO[x] <= PO[y], since it will process all such children of y before processing y.
> In RPO, it's just reversed)
>

I run into a runtime problem here. Exactly as you described,
phi-translate going through backedge may lead to incorrect pre result,
so I used the logic you suggested here to fix it. I added the testcase
in phi-translate-2.ll.

>
> Repository:
>   rL LLVM
>
> https://reviews.llvm.org/D32252
>
>
>


More information about the llvm-commits mailing list