https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265
--- Comment #27 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to Pedro Alves from comment #26) > I'm confused then -- how does making __builtin_memcmp natively work on > constexpr contexts address the "but then we'd have *three* versions" concern? Because we wouldn't need to touch the code except to add 'constexpr' to the function definitions. The version using a for-loop would be valid in constant expressions, and the version using __builtin_memcmp would be valid in constant expressions. We wouldn't have to use any new __constexpr_memcmp function. > Looking at the code, it does sound like you instead would want to > tweak __equal_aux to end up with __simple==false when all __equal_aux's > arguments are constant. Yes, that's what I meant by "It would be more sensible to just use the default (not memcmp-optimized) one ..." > As for the inlining/unrolling concern, if the compiler fails to completely > optimize out an inline pure function where all its inputs are known > constant, then it sounds like something that we'd want to fix in the > compiler, regardless? Yes, maybe, but normal optimizations are allowed (maybe even expected?) to give up at some point aren't they? e.g. calling std::equal on two arrays with hundreds of thousands of elements - would that be expected to be optimized out? When the std::equal call happens in a constant expression the compiler is *required* to evaluate it at compile-time (or fail to compile if it runs out of memory or some other implementation limit). When it's not in a constant expression the __builtin_constant_p result could be true but the compiler could still decide not to optimize out the actual for-loop and the comparisons, so we get the bad implementation at run-time when we could have called memcmp (I'm just guessing here, maybe that's not how the optimizers work).
