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

[David Blaikie]

On Mon, Oct 15, 2012 at 10:26 PM, Argyrios Kyrtzidis
<kyrtzidis at apple.com> 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,

Peanut gallery: I'm not really sure why this would be true. Once a
small function like that is inlined the unreachable might allow us to
prove certain properties of the parameters to the function, for
example. ((pre: x != 0) int func(int x) { if (x > 0) return 1; if (x <
0) return -1; } - now when you inline that function & you've written
correct code that meets the precondition, without having to assert it
anywhere, LLVM will be able to propagate that back & correctly assume
x != 0 for other parts of the caller that might benefit from such an
assumption)

full disclosure: not entirely true. We drop unreachable blocks
relatively early on, in SimplyCFG - so we don't actually prove too
much from them. (this swings both ways, though - if you're seeing
interesting things happen to invalid code that make them hard to
debug, I don't see any reason to believe that interesting things could
happen to valid code that make it more efficient)

> relinquishing any hope of finding the bug or figuring out what is going on
> in general.