On Mon, Jan 7, 2013 at 8:45 PM, Jeff Law <l...@redhat.com> wrote:
> On 01/05/2013 01:10 PM, Steven Bosscher wrote:
>>>
>>>
>>> Presumably BB7 was created in response to the builtin_unreachable?
>>
>>
>> Yes. The block only contains the BB_UNREACHABLE call. It is cleaned up
>> at the end of the GIMPLE passes pipeline, in the fold-all-builtins
>> pass (most __builtin_unreachable calls are, but not all).
>
> I think if you eliminate the block and the cleanup the CFG appropriately,
> the right thing will just happen.
>
>
>> The problem with this, is that __builtin_unreachable actually exposes
>> optimization opportunities: more const/copy props of "implicit sets"
>> in the predicate guarding the __builtin_unreachable call, more
>> optimistic value numbering, etc. It also helps improve maybe-unused
>> warnings accuracy. So simply removing these "dead ends" in the CFG is
>> probably not a good idea.
>
> ?!? By removing the empty unreachable block that's precisely what you
> enable. The block itself goes away and the branch leading to the block is
> simplified appropriately. That in turn will create larger basic blocks,
> enabling the const/copy propagations and similar optimizations.
>
> Finally removing unreachable paths was insired by the desire to eliminate
> false positives from maybe-{unused,uninitialized} and similar warnings.
>
> I'd be very curious to see the conditions under which removing the empty
> unreachable and appropriate cleanup of the CFG (including the underlying
> control statement) results in less optimizations and less precision in our
> may-warnings.
The issue is VRP - when you remove unreachable blocks you lose the
conditional statement as it is no longer necessary and thus the predicate
you can derive value-ranges from.
Maybe there are more examples. I can imagine false positive may-be
warnings then become must-be false positives.
There are clearly (as seen here) missed optimizations because we do
keep the unreachable blocks around.
Note that the whole point of the unreachable () excercise was to be
able to implement an assert () that even with -DNDEBUG leaves the
compiler with the same optimization opportunities (as of value-range
analysis) as with -UNDEBUG.
Richard.
