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

On 25 February 2015 at 10:58, Daniel Berlin <dberlin at dberlin.org>
wrote:
>
>
> On Wed, Feb 25, 2015 at 6:26 AM, Rafael Espíndola
> <rafael.espindola at gmail.com> wrote:
>>
>> > Maybe.
>> > My view is the ideal is either no-unreachable code, or unreachable
>> > blocks
>> > only contain terminators.
>>
>> I am definitely happy with both. What worries me is introducing a
>> special dominance rule for unreachable blocks.
>>
>> >> I don't think that rejecting
>> >>
>> >>   %a = getelementptr inbounds i8* %a, i64 1
>> >>
>> >> but accepting
>> >>
>> >>   %a = getelementptr inbounds i8* %b, i64 1
>> >>   %b = getelementptr inbounds i8* %a, i64 1
>> >>
>> >
>> > Does the verifier accept the latter right now?
>>
>> Yes. %a dominates %b and %b dominates %a, so it is valid.
>>
>
> So i'm confused.
>
> How does %b dominate %a?
all the zero paths from entry to %a pass by %b.

Cheers,
Rafael

On Wed, Feb 25, 2015 at 9:35 AM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:
> On 25 February 2015 at 10:58, Daniel Berlin <dberlin at dberlin.org>
wrote:
> >
> >
> > On Wed, Feb 25, 2015 at 6:26 AM, Rafael Espíndola
> > <rafael.espindola at gmail.com> wrote:
> >>
> >> > Maybe.
> >> > My view is the ideal is either no-unreachable code, or
unreachable
> >> > blocks
> >> > only contain terminators.
> >>
> >> I am definitely happy with both. What worries me is introducing a
> >> special dominance rule for unreachable blocks.
> >>
> >> >> I don't think that rejecting
> >> >>
> >> >>   %a = getelementptr inbounds i8* %a, i64 1
> >> >>
> >> >> but accepting
> >> >>
> >> >>   %a = getelementptr inbounds i8* %b, i64 1
> >> >>   %b = getelementptr inbounds i8* %a, i64 1
> >> >>
> >> >
> >> > Does the verifier accept the latter right now?
> >>
> >> Yes. %a dominates %b and %b dominates %a, so it is valid.
> >>
> >
> > So i'm confused.
> >
> > How does %b dominate %a?
>
> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150225/483df572/attachment.html>

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