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

Rafael EspĂ­ndola rafael.espindola at gmail.com
Wed Feb 25 06:26:02 PST 2015


> 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



More information about the llvm-dev mailing list