Hello,
(If you spend a lot of time looking at generated assembly you might
want to skip this one.)
As we all know the compiler's budget for optimizing C++ is an
implementation-defined metric where it knows best what is needed and
we are not supposed to be doing the compiler's job for it.
That is not how I or many people view things. We know most of the time compiler does very good job, but sometimes it fails.
I lost the code example, but recently I had an issues that compiler kept calling .size() in a for loop
(... i < vec.size();...) although vector size never changed.
I will make a couple proposals but let me explain the problems first.
The keyword const never mattered to the code generator before and it
seems the keyword constexpr doesn't matter now. The compiler may be
willing to execute constexpr code in a manifestly-const context but it
isn't going to do anything extra to optimize the generated assembly
otherwise. This is bothersome because everyone learning C++ is going
around acting like the constexpr keyword results in their runtime code
being more thoroughly evaluated at compile time when it doesn't even
matter at all.
This is not true. constexpr matters. Same for const. For example this code without constexpr will not compile.
constexpr int fun() {
return 10;
}
int main() {
const int sz = fun();
std::array<int, sz> arr;
return arr.size();
}
This is more of an education issue, but I wanted to
point out how dangerous the wording around things being made "possible
to evaluate at compile time" was for the uninitiated.
Keyword constexpr on functions and variables has different guarantees and I agree that is confusing for people learning C++.
Meanwhile gcc/clang are still perfectly happy to inline and execute
arbitrary non-const code at link time clear across different
translation units. Let me give you an example of code inlining using a
simple insertion sort template that just uses pointers and operator<:
int example1() {
int x[3] = { 7, 3 };
hxinsertion_sort(x+0, x+2);
printf("%d %d", x[0], x[1]);
}
This results in the following assembly:
.string "%d %d"
sub rsp, 8
mov edx, 7
mov esi, 3
xor eax, eax
mov edi, OFFSET FLAT:.LC0
call "printf"
This means the two numbers were sorted at compile time without any of
the new C++ constant evaluation machinery involved. Meanwhile, if you
write that with std::sort you get this:
You can easily force sorting at compile time:
[[gnu::noinline]]
void example2() {
constexpr auto x =[] {
std::array arr{ 7, 3, 0};
std::ranges::sort(arr.data(), arr.data()+2);
return arr;
}();
printf("%d %d\n", x[0], x[1]);
}
example2():
lea rdi,[rip+0xe69] # 2010 <_IO_stdin_used+0x10>
xor esi,esi
mov edx,0x3
xor eax,eax
jmp 1030 <printf@plt>
example2():
mov edx, 3
xor esi, esi
mov edi, OFFSET FLAT:.LC0
xor eax, eax
jmp printf
// I shortened your array from 3 to 2 elements, but if you want you can create 3 element std::array and then sort just first 2 elements, constexpr works fine.
Interesting that gcc manages to do the optimization even for your example with std::sort while clang fails.
Advantage of constexpr here is the following: when I see constexpr arr = something
I know arr is computed at compile time. In real big projects where I do not have time to look at asm for entire project this is a huge benefit in productivity.
So, my first proposal is to have a template library that can operate
using pointers and arrays without extra templated abstraction layers.
Then the compiler does a better job, your compiler errors are nice and
clean and the debugger is a relative joy to use. And when it comes to
safety, the clang sanitizers can be used to make raw pointers just as
safe as iterators these days.
I think you are missing important point about iterators. Can your pointer based approach sort std::deque? std::sort can.
If hxsort can not sort std::deque you are basically asking for people to have multiple implementations of std::sort.
Also insertion sort has worst case complexity not allowed in C++, and more importantly for your example implementation is
much simpler than std::sort. So it may not be the iterators that are causing compiler to fail to optimize, but the difference in complexity
of sort implementations.
I have seen a professionally written C++ codebase spend 3% of
its time inside std::vector::operator[] with all optimizations turned
on. (This is why the standard library gets banned from real-time
embedded projects.) If we required support for -O9 and told everyone
they may have to let the compiler run overnight then at least all this
talk about what is possible with compile time evaluation would be less
deceptive.
While this idea is tempting I think this is not for C++ standard, more of something that compiler people could do.
But I presume you are not first person to come up with this idea. My guess (we would need to get definitive answer from compiler people) as to why there are no flags like O9 is:
- you can control this behavior with other flags
- gains would be minimal, e.g. problem you described with sort is because of compiler optimization issues, not because it did not had enough time budget to get it correctly