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

[Richard Smith]

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.