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

> 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.
>> * Having the verifier reject unreachable code at the end of a pass
>> would probably have made it easier to identify and reduce the issue,
>> as the verifier would always detect the unreachable code but the code
>> has to be in a particular shape to crash gvn.
>>
>> On the testcase reduction side of things, the only think I would
>> insist on is that bb1 still counts as reachable in
>>
>> bb0:
>> br i1 false, label %bb1, label %bb2
>
>
> Sure.
> This is in fact, what i think the ideal for "leave unreachable
blocks"
> around looks like - we don't mess with the cfg, but we do get rid of
all
> other instructions/uses.
> As i've said, this is what almost all passes *already do*.
OK, short of some new argument the other side I agree with you. Given
that "bb1" is still reachable in the "br i1 false" case, I
don't see a
lot of value in allowing unreachable blocks with just terminators in
it. I would suggest just making the verifier reject trivially forward
unreachable blocks.

At least initially, I would keep utility functions accepting
unreachable and keep a verifier mode that accepts it to so that we can
test them.

Cheers,
Rafael

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?

The use of %b in  %a is use-before-def

Even if the block dominates itself, definitions would still have to locally
dominate (IE appear before) the use.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150225/e801ea3e/attachment.html>

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