[cfe-commits] r165273 - in /cfe/trunk: lib/CodeGen/CodeGenFunction.cpp test/CodeGen/catch-undef-behavior.c test/CodeGenCXX/catch-undef-behavior.cpp test/CodeGenCXX/return.cpp

[Argyrios Kyrtzidis]

On Jan 22, 2013, at 5:55 PM, Chandler Carruth <chandlerc at google.com> wrote:

> On Tue, Jan 22, 2013 at 5:42 PM, Argyrios Kyrtzidis <kyrtzidis at apple.com> wrote:
> On Jan 22, 2013, at 5:23 PM, Chandler Carruth <chandlerc at google.com> wrote:
> 
>> On Tue, Jan 22, 2013 at 4:15 PM, Daniel Dunbar <daniel at zuster.org> wrote:
>> Hi Richard,
>> 
>> I object pretty strongly to using unreachable here for C++ code bases.
>> 
>> There was some discussion surrounding this, and I'm still pretty strongly in favor of it...
> 
> IMHO you still haven't given enough justification; your proposed optimization opportunity in http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-October/025326.html is specific to a full covered switch, which can be handled with an optimization that targets this case.
> 
> It is applicable to any circumstance where there is a programmer-known invariant that all paths terminate in a return which is not statically determinable. I've seen both predicated code with if/else chains of this form, and switches.

This is in user code that doesn't get a -Wreturn-type warning (thus forcing putting an 'unreachable' in source code which is a "Good Thing"(TM) because it makes the invariant explicit) ? Could you give a non-switch example ?

> 
> But I actually think we're approaching this from the wrong direction. The C++ standard is extremely clear that this is UB. Given that, I think we should aggressively tell users about this problem with their code.

Ok, but emitting 'unreachable' does not in any way "tell users about this problem with their code", it's doing the opposite, it takes a bug and messes up the code beyond hope of recognition for the problem.

> If the optimization benefits aren't worthwhile, then I would argue for emitting llvm.trap in *all* cases rather than just in non-optimized builds.

FWIW, I don't have a strong opinion on this, as long as the trap is not treated like unreachable by the backend.

> While I think the optimization benefits are both easy to get and worth it, I don't have a collection of benchmarks that rely on it so I'm not going to fight tooth and nail for it. I just don't understand sacrificing it when we don't have to.
> 
> 
> However, if you're arguing that Clang should define the behavior of falling off the end of a function in C++ as an extension, I think that requires significant evidence of the problems this causes and following the usual Clang policies a move toward defining the behavior in the standard. I think the biggest problem with that is going to be coming up with a useful, rational description of what this defined behavior is in the C++ language. There are many differences between C++ and C here that (IMO) make it very challenging to specify.

Standardizing the behavior in the language is related but a bit off-topic, maybe another thread should be started; this is about the specific changes in the clang frontend.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130123/9f40a004/attachment.html>