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

[Argyrios Kyrtzidis]

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 ?

> 
> -Argyrios
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

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