[llvm-commits] [llvm] r141177 - in /llvm/trunk: lib/Transforms/Scalar/GVN.cpp test/Transforms/GVN/condprop.ll test/Transforms/GVN/phi-translate.ll

[David Blaikie]

On Tue, Oct 11, 2011 at 10:00 AM, Nick Lewycky <nlewycky at google.com> wrote:

> On 11 October 2011 02:11, Duncan Sands <baldrick at free.fr> wrote:
>
>> Hi David,
>>
>>  It's really close, but not quite. Given the attached llvm assembly, the
>>> function
>>> call is correctly devirtualized (but the branch is left in). But if you
>>> comment
>>> out the first ret void (in the vtable.ne <http://vtable.ne> block) &
>>> comment in
>>>
>>> the unreachable instruction then the branch is removed by the simplifycfg
>>> pass &
>>> no interesting information about the condition is preserved for use by
>>> the GVN
>>> pass so the call is still indirect/virtual.
>>>
>>
>> I thought there was a plan that a branch to a block containing only
>> unreachable
>> shouldn't be removed by the IR optimizers (instead codegen would remove
>> it).  I
>> even though Nick implemented this.  But apparently not...
>>
>
> Implemented but never committed. It had a lot of undesirable side-effects
> in terms of preventing other optimizations from happening.
>
>

Yeah, I can see how it could hinder other optimizations - though their
presence hinders some optimizations (such as this one) too. It really limits
the power of the unreachable instruction if all it does is cause the
block to be removed up-front.

A somewhat naive suggestion: would it make sense to run some optimizations
before removing unreachable blocks & then again after they've been removed?

[& in addition: does this still seem like the right approach to the original
bug or are there other options to consider?]

Thanks,
- David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20111011/deea1a89/attachment.html>