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

Argyrios Kyrtzidis kyrtzidis at apple.com
Mon Oct 15 22:26:41 PDT 2012


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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121015/37f3247c/attachment.html>


More information about the cfe-dev mailing list