https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86590
--- Comment #21 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Richard Biener from comment #20) > (In reply to Pedro Alves from comment #19) > > > confuses us because of the stupid structure of __constant_string_p. > > > > Yes, a stupid workaround for a stupid __builtin_strlen, which is being > > punished by a stupid optimizer. ;-) > > > > I'll be the first to say "good riddance" when this disappears, but I'm > > honestly surprised the optimizers can't _always_ inline all of that, given > > it's basically just "do I know this at compile time" checks... I'd think > > that fixing that would help generate better code in other uses of > > __builtin_constant_p in other codebases. As I mentioned in > > <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265#c32>, interestingly the > > trick made some cases optimize _better_, which kind of suggests to me that > > __builtin_foo functions are missing some comparing-known-constant-objects > > optimizations. > > The failure is not in inlining but in not optimizing the "constexpr" > part of the code in comment#9, that is, we fail to optimize > > char *s = "Hello World"; > while (__builtin_constant_p(*__s) && *__s) > __s++; > res = __builtin_constant_p(*__s); > > in the regular optimizers early enough which all do not do unbound > expression evaluation (as constexpr is doing). Neither optimistic > constant propagation or value-numbering algorithms handle this. > For the small string loop unrolling might do the trick but IIRC > there is a bug about not being able to compute the number of iterations > for a loop iterating over a constant string, so ... > > We do handle it at the point we give up and say __builtin_constant_p () > evaluates to false. But that's too late and we are not able to optimize > things away after that. > > _Eventually_ we should change that point from the first DOM pass to the > value-numbering pass after IPA inlining. Like with the following, which will give up earlier: Index: gcc/tree-ssa-sccvn.c =================================================================== --- gcc/tree-ssa-sccvn.c (revision 262899) +++ gcc/tree-ssa-sccvn.c (working copy) @@ -4193,6 +4193,14 @@ visit_use (tree use) SSA_VAL (gimple_vuse (call_stmt))); goto done; } + /* After IPA inlining either we can simplify __builtin_constant_p + or we assume it is false. */ + else if (cfun->after_inlining + && gimple_call_builtin_p (call_stmt, BUILT_IN_CONSTANT_P)) + { + changed = set_ssa_val_to (lhs, build_zero_cst (TREE_TYPE (lhs))); + goto done; + } else if (SSA_NAME_OCCURS_IN_ABNORMAL_PHI (lhs)) { changed = defs_to_varying (call_stmt); That nearly solves the issue but appearantly leaves us with _M_construct.constprop calls that are possibly throwing compared to the calls surviving with -std=c++14.
