On Mar 16, 2013, at 10:14 AM, Argyrios Kyrtzidis <[email protected]> wrote: > The attached patch adds a check so that, if we flow off the end of a > value-returning function, the implicit unreachable will only be emitted if > the returning block is empty. > For example: > > int baz(int x) { > switch (x) { > case 1: return 10; > case 2: return 20; > } > // implicit unreachable is inserted > } > > int baz2(int x) { > switch (x) { > case 1: return 10; > case 2: return 20; > } > foo(); > // no unreachable > } > > As a consequence, functions that have no returns, will not get the implicit > unreachable: > > int baz2(int x) { > foo(); > // no unreachable > } > > > I believe this allows taking advantage of the optimization opportunities that > the implicit unreachable intended, in a safer manner.
Hmm. There's a pretty large spectrum of ways in which something could end up with a non-empty return block while still conceptually falling off the end in a way we'd like to optimize. We were talking about maybe re-using the same logic that we'd use for -Wreturn-type; what's the value in doing this intermediate stage? Also, if we do decide to do this, please don't use empty(); that can lead to us generating semantically different code based on the presence of debug info. I believe you can instead ask whether getFirstNonPHIOrDbgOrLifetime() returns null. John. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
