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. 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. 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. 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.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
