On Jan 22, 2013, at 5:55 PM, Chandler Carruth <[email protected]> wrote:
> On Tue, Jan 22, 2013 at 5:42 PM, Argyrios Kyrtzidis <[email protected]> > wrote: > On Jan 22, 2013, at 5:23 PM, Chandler Carruth <[email protected]> wrote: > >> On Tue, Jan 22, 2013 at 4:15 PM, Daniel Dunbar <[email protected]> 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 > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
