Use `if consteval` after compiler support arrives
https://en.cppreference.com/w/cpp/23 indicates that Clang 14 began supporting C++23 WG21-P1938R3 if consteval, and it's available as Future Technology in C++20 mode: https://godbolt.org/z/MhjoaxW6a
For C1XX, MSVC-PR-598052 was merged on 2024-12-12 and will ship in VS 2022 17.14 Preview 1. It was implemented as Future Technology that we can access with a suppressible warning (C5282). Presumably this also goes back to C++20 but not earlier (haven't checked) as consteval became a keyword in C++20.
For EDG in VS 2022 17.13 Preview 2, if consteval appears to be supported in C++23 mode, but C++20 mode emits a syntax error. (As EDG isn't a codegen compiler for us, this is the least important.)
I haven't checked CUDA.
While I'm not looking forward to macroization, we should look into using if consteval after C1XX support ships, because it can significantly improve debug codegen, and should give the release optimizer slightly less work to do.
This would be particularly nice for our hand-vectorized algorithms, which currently produce enormous debug codegen. When not optimizing the compiler doesn't realize that std::is_constant_evaluated()) is a constant expression, so it emits code for both the vectorized and non-vectorized paths. We've gotten some nasty glares from the compiler backend folk who monitor codegen size because of this.
I suppose we can replace the pattern:
if constexpr (/* the algorithm can be hand-vectorized for the pertinent types */) {
if (!std::is_constant_evaluated()) {
/* vectorized implementation */
}
}
/* vanilla implementation */
with
if consteval {
vanilla_implementation();
} else if constexpr (/* the algorithm can be hand-vectorized for the pertinent types */) {
/* vectorized implementation */
} else {
vanilla_implementation();
}
which requires the vanilla (non-vectorized) implementation to be extracted into a separate function (perhaps a lambda) to avoid duplication. This should reduce debug codegen since if consteval and if constexpr are both compile-time branches.
(Shout if you see a way to perform the dispatch that doesn't require repetition and/or extraction - I don't.)
I went to check this on godbolt and forgot that MSVC doesn't quite have if constexpr yet, but would this fit the bill?
if constexpr (/* the algorithm can be hand-vectorized for the pertinent types */) {
if consteval {
/* do nothing */
} else {
/* vectorized implementation and a return */
}
}
/* vanilla implementation */
or would that still have the same behavior?
(Shout if you see a way to perform the dispatch that doesn't require repetition and/or extraction - I don't.)
I think this is the cleanest way, if you have time ptal. While it is still 2 functions I still find it relatively clean since dispatch and logic are split and vanilla and simd logic can live in same function without repetition. You might get a some more nasty compiler dev glares because it involves more templates so it may slow down compile...
https://godbolt.org/z/s3rbo8vaa
@DeadlyRedCube The "fall through" results in codegen being emitted for both vectorized and vanilla, since the FE doesn't perform any sort of dead code elimination and the BE under /Od doesn't.
@StephanTLavavej Ah, darn. Was hoping since it was a clear compile time branch that it could do it, but that makes sense.
(Shout if you see a way to perform the dispatch that doesn't require repetition and/or extraction - I don't.)
We'd ideally wanted the following statements:
if consteval (additional-condition-constant-expression) { ... }if !consteval (additional-condition-constant-expression) { ... }
The latter would be ideal match here.
Currently, in VS 2022 17.14 Preview 3+:
- MSVC and Clang support
if constevalin C++20 mode but don't define__cpp_if_constevaluntil C++23; - EDG only supports
if constevalsince C++23 mode while starting defining__cpp_if_constevalin C++23; - I haven't investigated CUDA. But given its documentation hasn't mentioned C++23 yet, probably it doesn't support
if consteval.
In all, defined(__cpp_if_consteval) is probably reliable, but we should specially handle Clang and MSVC. I'm not sure whether there's some reliable MSVC-only predefined macro. STL doesn't seem to rely on such a thing.