[PATCH] D27163: Introduce -f[no-]strict-return flag that controls code generation for C++'s undefined behaviour return optimisation

[Alex Lorenz via Phabricator via cfe-commits]

arphaman added inline comments.


================
Comment at: include/clang/Driver/Options.td:1324
+  HelpText<"Use C++ undefined behaviour optimization for control flow paths"
+     "that reach the end of the function without executing a required return">;
+def fno_strict_return : Flag<["-"], "fno-strict-return">, Group<f_Group>,
----------------
mehdi_amini wrote:
> Quuxplusone wrote:
> > Nit: looks like Clang spells it "behavior"?
> > 
> > Nit: I'm still pedantically uncomfortable with describing the strict-return behavior as an "optimization". I suggest rephrasing this as "-fstrict-return: Treat control flow paths that fall off the end of a non-void function as unreachable."
> > 
> > (I notice that neither -fstrict-aliasing nor -fstrict-overflow have any help text at all.)
> >  I suggest rephrasing this as "-fstrict-return: Treat control flow paths that fall off the end of a non-void function as unreachable."
> 
> Is it an accurate description? `-fno-strict-return` would only disable this for trivial types.
> Nit: looks like Clang spells it "behavior"?

Thanks, I forgot to use the US spelling.

> Nit: I'm still pedantically uncomfortable with describing the strict-return behavior as an "optimization". I suggest rephrasing this as "-fstrict-return: Treat control flow paths that fall off the end of a non-void function as unreachable."

I like your suggestion, but Mehdi brought up a good point. Maybe "Always treat control flow paths that fall off the end of a non-void function as unreachable" would be better, since then `-fno-strict-return` would imply that the optimisation can still be used sometimes, like for the non-trivially destructible types.


Repository:
  rL LLVM

https://reviews.llvm.org/D27163