[cfe-dev] Reaching the end of a value-returning function in C++
John McCall
rjmccall at apple.com
Tue Oct 16 10:11:12 PDT 2012
On Oct 16, 2012, at 10:05 AM, Matthieu Monrocq wrote:
> On Tue, Oct 16, 2012 at 6:04 PM, 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.
>
> Actually Richard did fix a couple issue in libc++ headers (missing "return *this" in swaps/assignment operators for what I could see), so yes, c++ system headers (and possibly c platform headers ?)
Okay.
It shouldn't happen with C platform headers because I believe this is limited to returns of C++ types (references and things with non-trivial constructors), right?
I guess I don't really have a problem with using @llvm.trap here unconditionally, absent any sign that anyone is using this as a portable idiom for unreachability.
John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121016/0283a417/attachment.html>
More information about the cfe-dev
mailing list