[PATCH] D69865: [IR] PR27065: Part2. Fix BasicBlock::removePredecessor to not break SSA form.

Denis Bakhvalov via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Nov 7 10:47:17 PST 2019


dendibakh added a comment.

I'm not arguing that passes should not look into unreachable code.

But in this exact case, BasicBlock::removePredecessor is pretty much general API, not limited to particular pass. We are not 100% sure that the broken code will be unreachable. 
Consider this:

  define i32 @f(i1 %cmp, i8 *%call) {
  entry:
    br i1 %cmp, label %phi.bb, label %ret.bb
  phi.bb:
    %ptr.1 = phi i8* [ %call, %entry],[ %inc.ptr1, %use.bb ]
    br label %use.bb
  use.bb:
    %inc.ptr1 = getelementptr inbounds i8, i8* %ptr.1, i64 1
    br i1 %cmp, label %ret.bb, label %phi.bb
  ret.bb:
    ret i32 0
  }

After doing:

  PhiBB->removePredecessor(EntryBB);

We have:

  define i32 @f(i1 %cmp, i8* %call) {
  entry:
    br i1 %cmp, label %phi.bb, label %ret.bb				<== edge entry->phi.bb will be removed later
  phi.bb:
    br label %use.bb
  use.bb:
    %inc.ptr1 = getelementptr inbounds i8, i8* %inc.ptr1, i64 1 		<== broken
    br i1 %cmp, label %ret.bb, label %phi.bb
  ret.bb:
    ret i32 0
  }

User can later decide to link phi.bb into some other place (outlining, for example). Can that happen? If yes, it is not unreachable code anymore.

To summarize my point: even if we know the code is dead and noone will look into it, I don't see benefits of allowing it to be broken. In this particular case, (I hope) it will require no additional changes, since passes do not look into unreachable code and do not care if it is valid or not.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69865





More information about the llvm-commits mailing list