On Mar 18, 2013, at 7:05 PM, John McCall <[email protected]> wrote: > On Mar 18, 2013, at 6:28 PM, Argyrios Kyrtzidis <[email protected]> wrote: >> On Mar 17, 2013, at 4:51 PM, John McCall <[email protected]> wrote: >>> 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. >> >> Could you give some examples ? > > Mostly, anything that needs a cleanup. You could work around this by > checking before we pop out of top-level cleanups, though. On the other hand, > there are a lot of ways that you can end up with an empty IR block at the end > of a function that have nothing to do with whatever semantic condition you're > trying to capture. I really wouldn't want to explain some of these > differences: "The final line in your function had a conditional cleanup in > it, and that branch left us with an empty block, so we decided the end was > unreachable." > > If you want to avoid making a CFG or computing -Wreturn-type, you should make > this heuristically based on the final statement in the function, possibly > recursively. Come up with some straightforward syntactic rule. But, having > thought about it, using IR structure would be a disaster.
Well, it would be impossible to be _more_ disaster than what we currently have, but this is another topic. If you don't think checking the IR is safe enough, your point is well taken. Thanks for reviewing! > > John.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
