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

[Daniel Berlin]

On Wed, Feb 25, 2015 at 10:41 AM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:

> >> 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.
>

It also doesn't explain "why" it decided this is the case :)

>
> 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?
>

Yes, if we consider unreachable blocks to dominate everything (IE the
dom-tree is not acyclic), it is just as bad of a result.


>
> It looks like a case where we would just be getting a bigger rug to
> swipe dirt under.


Yes, you are likely right.


> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150225/1867473c/attachment.html>