[PATCH] D22305: [BasicAA] Strip phi nodes, when all incoming values are the same.

Daniel Berlin via llvm-commits llvm-commits at lists.llvm.org
Thu Jul 14 10:11:11 PDT 2016


On Thu, Jul 14, 2016 at 7:09 AM, Ehsan A Amiri <amehsan at ca.ibm.com> wrote:

> This is order of events:
>
> This order cannot be correct if the solution I gave (or adding
simplification to *some place in GVN*) does not work.  Or GVN is broken in
other ways.


> 1) GVN starts looking at the function. At this point the phi node has two
> different incoming values.
> 2) GVN performs an RAUW. The phi is converted to the one that has two
> identincal incoming values.
>

At this point, it should now process the phi instruction again before it
processes the load, because it is doing a reverse postorder traversal.
When it did that, the phi should have been simplified
So why did that not happen?

>
> Given the complexity of fixing the real problem,
>

Look, i understand why you want to just fix this in AA and be done with it.
Really, I do.

I understand you have spent a lot of time on this bug, and I greatly
appreciate that.
But I really want to understand what is going on before we try to actually
fix it.
I have a good understanding of what happens once the bad answer gets into
memdep (and thank you for that!), but i still have trouble seeing why it
lived long enough to get there.

To that end, so you don't have to spend more time running around for me,
 i'll take over this bug, and either figure out why GVN lets this PHI live
to the point it gets an AA query about it (and fix it/decide it can't be
fixed), or commit the AA patch for you if we decide it can't be fixed.

My ETA is by friday.

I assume the testcase in the bug is the one we are still using, right?
(If not, if you can attach it, that would be helpful)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160714/56295350/attachment.html>


More information about the llvm-commits mailing list