Jump Theading/GVN bug

Philip Reames listmail at philipreames.com
Mon Feb 23 10:40:41 PST 2015


Can we move the general discussion to llvm-dev?  This probably warrants 
a wider audience.

On 02/23/2015 10:07 AM, Hal Finkel wrote:
> ----- Original Message -----
>> From: "Chandler Carruth" <chandlerc at google.com>
>> To: "Daniel Berlin" <dberlin at dberlin.org>
>> Cc: llvm-commits at cs.uiuc.edu, "Katya Romanova" <Katya_Romanova at playstation.sony.com>
>> Sent: Monday, February 23, 2015 11:55:18 AM
>> Subject: Re: Jump Theading/GVN bug
>>
>> On Mon, Feb 23, 2015 at 8:21 AM, Daniel Berlin < dberlin at dberlin.org
>>> wrote:
>>
>> On Mon Feb 23 2015 at 7:38:37 AM Rafael Espíndola <
>> rafael.espindola at gmail.com > wrote:
>>
>>
>>>> This instruction doesn’t appear to be well formed. However, one
>>>> could
>>>> argue that it is – formally %2 def does dominate all %2 uses
>>>> because both
>>>> are located in an unreachable block, so every path to the use is
>>>> passing
>>>> through the def (because there are 0 paths like that).
>>>>
>>>> That is likely the reason why –verify doesn’t complain about it.
>>>
>>> Why is jump-threading creating this funky instruction?
>> It is well formed. I agree with Hal: it might be a quality
>> improvement
>> to generate tidier IR from jump-threading, but GVN has to handle
>> whatever input passes the verifier.
>>
>>
>>
>> Then, IMHO, we should start the long process of making
>> forward-unreachable code not acceptable except inside a single pass
>> (IE at the end of each pass, there should be no unreachable code).
>>
>>
>> There are a very very small number of passes that generate such code,
>> and it's not that difficult to fix them to make them not do that.
>> I will write up a longer reply soon, but I strongly disagree. I think
>> this would be a really bad direction for LLVM to move in.
> Well I am curious...
>
> Thinking about it, I'm not sure how much I care about not having unreachable code, so much as I care about not allowing unreachable nonsense code (such as instructions that depend on themselves). Processing unreachable code does add compile-time overhead, however, and passes likely to create it should do more to clean up after themselves (at least when doing so is a locally decidable problem, if not always).
>
>   -Hal
>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>





More information about the llvm-commits mailing list