https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86590
--- Comment #20 from Richard Biener <rguenth at gcc dot gnu.org> --- (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.
