[cfe-dev] Reaching the end of a value-returning function in C++

[Chandler Carruth]

On Thu, Oct 25, 2012 at 2:18 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> On Thu, Oct 25, 2012 at 10:54 AM, Argyrios Kyrtzidis
> <kyrtzidis at apple.com> wrote:
>>
>> On Oct 16, 2012, at 10:15 AM, Argyrios Kyrtzidis <kyrtzidis at apple.com>
>> wrote:
>>
>> On Oct 16, 2012, at 9:04 AM, John McCall <rjmccall at apple.com> wrote:
>>
>> On Oct 15, 2012, at 10:26 PM, Argyrios Kyrtzidis wrote:
>>
>> On Oct 15, 2012, at 9:45 PM, John McCall <rjmccall at apple.com> wrote:
>>
>> On Oct 15, 2012, at 9:34 PM, Richard Smith wrote:
>>
>> On Mon, Oct 15, 2012 at 11:39 AM, Argyrios Kyrtzidis <kyrtzidis at apple.com>
>> wrote:
>>>
>>> Unless I'm missing something, this will benefit functions that are not
>>> checked with -Wreturn-type and are supposed to be unreachable in some path
>>> but are not marked as such.
>>>
>>> I'd prefer that these functions are actually marked as 'unreachable' in
>>> source code, instead of depending on the compiler implicitly assuming that
>>> in order to get such an optimization.
>>
>>
>> I agree, but if they're not marked 'unreachable' in the source code, what IR
>> would you want to produce for code paths which fall off the end?
>> @llvm.trap() at -O0 and unreachable otherwise seems reasonable to me; would
>> you prefer something else? (Perhaps always emitting a call to @llvm.trap?)
>>
>>
>> FWIW, I endorse using 'unreachable' here outside of -O0.
>>
>>
>> Compared to 'unreachable', I prefer always emitting a call to @llvm.trap.
>>
>> Please keep in mind that there's debugging and investigation of crash
>> reports from -Os/O2 code as well..
>> I didn't yet see an argument that there's enough optimization opportunity in
>> practical terms to justify the havoc that 'unreachable' will cause with a
>> buggy function.
>> Valid code is, in reality, going to use 'unreachable' marks and 'noreturn'
>> functions, so all we are going to achieve is "speed up" buggy code,
>> relinquishing any hope of finding the bug or figuring out what is going on
>> in general.
>>
>>
>> Is there a case where we wouldn't actually warn before doing this?  Buggy
>> C++ system headers?
>>
>> John.
>>
>>
>> If you believe that the warning will catch all such bugs, then the
>> "optimization" is actually useless (as in "it won't get used").
>>
>> If, on the other hand you believe that warnings are not panacea and there's
>> a chance that such a bug will slip by (already did), which is when the
>> 'unreachable' will kick in, then at best we are obfuscating the bug and and
>> at worst we are creating a mess.
>> Is there a case where this is worth it ?
>>
>>
>> Ping, are there objections to avoid using unreachable, but trap instead ?
>
> No objection from me.

I think we should use unreachable.

This is a very real optimization that can have significant performance
impacts. Notably, it allows us to delete substantial amounts of code
that the C and C++ standard says *will not be executed*. We should
take full advantage of this.

We cannot curtail every optimization opportunity because somewhere
someone might have written buggy code. Instead we should build tools
to find such buggy code effectively. The behavior at -O0 and the use
of -fcatch-undefined-behavior both seem reasonable ways to produce a
trap and catch the behavior. Absent those, I think we should be very
aggressive about simplifying these control flow construts as much as
the standard allows us to simplify it.

To answer why we need the semantic unreachable to get these
optimization opportunities: in a word, inlining. When inlining
collapses the CFG of a function, having the unreachable hint can be
essential to selecting the proper representation.