[PATCH] D80399: [Local] Prevent `invertCondition` from creating a redundant instruction

Ehud Katz via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sun May 24 01:34:12 PDT 2020


ekatz marked an inline comment as done.
ekatz added inline comments.


================
Comment at: llvm/lib/Transforms/Utils/Local.cpp:3067-3068
-    if (isa<PHINode>(Inst)) {
-      // FIXME: This fails if the inversion is to be used in a
-      // subsequent PHINode in the same basic block.
-      Inverted->insertBefore(&*Parent->getFirstInsertionPt());
----------------
foad wrote:
> sameerds wrote:
> > foad wrote:
> > > sameerds wrote:
> > > > I don't think the current change fixes this issue. As far as I can see, it can't even be fixed inside this function since the intended use is not visible here. It might help to move the comment to the beginning of the function so that it is more obvious to users.
> > > I think the FIXME is completely misguided. PHIs are defined to happen simultaneously so there is no "subsequent PHINode".
> > I don't have a concrete example, so I'll put this as a question: Even if all PHI's "happen" simultaneously, they do "occur" in a sequence. If there are two phi's one after the other, then does the first phi "dominate" the next phi? If yes, it can potentially be an argument along some control flow edge. Then something complicated like the structurizer may decide to invert the value of the first phi and the insertion will fail. Is that a legal scenario?
> > If there are two phi's one after the other, then does the first phi "dominate" the next phi?
> 
> No.
A PHI function ("Node" for our purposes) receives a block as an argument, which then redirects to a value. This is done at the beginning of a block, as if "before entering it". It is actually equivalent to MLIR "block arguments" (sending arguments to a basic block, the same way as sent to a function).
Arguments are precalculated in the caller's block, and sent as they are to the new block. They cannot have dependency on each other.
A PHI node cannot be dependent on another PHI node that doesn't come from the exit of a basic-block to the entry of the node's parent basic-block.
Hope I made it clearer.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D80399/new/

https://reviews.llvm.org/D80399





More information about the llvm-commits mailing list