[LLVMdev] Jump Theading/GVN bug - moving discussion to llvm-dev

Rafael EspĂ­ndola rafael.espindola at gmail.com
Wed Feb 25 10:41:29 PST 2015


>> all the zero paths from entry to %a pass by %b.
>
>
> That is a graph-wise definition, sure.
> So, this is an interesting definition, and maybe this is part of the source
> of the problem.
>
> For SSA, at least GCC requires that both "definition block dominates use
> block" (which would be true here), *and*
> that "definition appears before use in block" (IE definition locally
> dominates use).
>
> IE it has to pass both DT->dominates(block(%b), block(%a)) and
> DT->dominates(%b, %a).
>
> LLVM special cases "not reachable from entry", and says that no matter what,
> #2 is true if %a is unreachable.
>
> The code is, IMHO, not even self-consistent
>
>
>    // Any unreachable use is dominated, even if Def == User.
>    if (!isReachableFromEntry(UseBB))
>      return true;
>
>    // Unreachable definitions don't dominate anything.
>    if (!isReachableFromEntry(DefBB))
>      return false;
>
>
>
> Riddle me this: If unreachable definitions dominate nothing, how are
> unreachable uses always dominated by their unreachable defs?

I think the comment is just just missing an "otherwise" at the start.

If we were to define dominance rules as you suggest, we would still accept

define void @f() {
bb0:
  ret void
bb1:
  %a = getelementptr inbounds i8* %b, i64 1
  ret void
bb2:
  %b = getelementptr inbounds i8* %a, i64 1
  ret void
}

Since bb1 dominates bb2 and bb2 dominates bb1, no?

It looks like a case where we would just be getting a bigger rug to
swipe dirt under. I think the definition we have is sound. It creates
odd cases, but, as you point out, it looks like we can just require
passes to cleanup such cases by deleting forward unreachable code.

Cheers,
Rafael



More information about the llvm-dev mailing list