On Fri, May 27, 2022 at 11:13 PM Laleh Beni via Gcc wrote:
>
> GCC compiler is able to understand if the prefix of an array holds
> constant/static data and apply compiler optimizations on that partial
> constant part of the array, however, it seems that it is not leveraging
> this information in all cases.
>
> On understanding the behavior of compiler optimization for partially
> constant arrays and especially how the loop splitting pass could have an
> influence on the potential constant related optimizations such as constant
> folding I am using the following example:
>
>
>
> Considering an array where the prefix of that array is compile-time
> constant data, and the rest of the array is runtime data, should the
> compiler be able to optimize the calculation for the first part of the
> array?
>
> Let's look at the below example:
>
>
>
> You can see the code and its assembly here: https://godbolt.org/z/xjxbz431b
>
>
>
> #include
>
> inline int sum(const int array[], size_t len) {
>
> int res = 0;
>
> for (size_t i = 0; i < len; i++) {
>
> res += array[i];
>
> }
>
> return res;
>
> }
>
> int main(int argc, char** argv)
>
> {
>
> int arr1[6] = {200,2,3, argc, argc+1, argc+2};
>
> return sum(arr1, 6);
>
> }
>
>
>
>
>
> In our sum function we are measuring the some of the array elements, where
> the first half of it is static compile-time constants and the second half
> are dynamic data.
>
> When we compile this with the "x86-64 GCC 12.1" compiler with "-O3
> -std=c++2a " flags, we get the following assembly code:
>
>
>
> main:
>
> mov rax, QWORD PTR .LC0[rip]
>
> mov DWORD PTR [rsp-28], edi
>
> mov DWORD PTR [rsp-32], 3
>
> movqxmm1, QWORD PTR [rsp-32]
>
> mov QWORD PTR [rsp-40], rax
>
> movqxmm0, QWORD PTR [rsp-40]
>
> lea eax, [rdi+1]
>
> add edi, 2
>
> mov DWORD PTR [rsp-24], eax
>
> paddd xmm0, xmm1
>
> mov DWORD PTR [rsp-20], edi
>
> movqxmm1, QWORD PTR [rsp-24]
>
> paddd xmm0, xmm1
>
> movdeax, xmm0
>
> pshufd xmm2, xmm0, 0xe5
>
> movdedx, xmm2
>
> add eax, edx
>
> ret
>
> .LC0:
>
> .long 200
>
> .long 2
>
>
>
>
>
> However, if we add an “if” condition in the loop for calculating the result
> of the sum, the if condition seems to enable the loop splitting pass:
>
>
>
> You can see the code and its assembly here: https://godbolt.org/z/ejecbjMKG
>
>
>
> #include
>
> inline int sum(const int array[], size_t len) {
>
> int res = 0;
>
> for (size_t i = 0; i < len; i++) {
>
> if (i < 1)
>
> res += array[i];
>
> else
>
> res += array[i];
>
> }
>
> return res;
>
> }
>
> int main(int argc, char** argv)
>
> {
>
> int arr1[6] = {200,2,3, argc, argc+1, argc+2};
>
> return sum(arr1, 6);
>
> }
>
>
>
>
>
> we get the following assembly code:
>
>
>
> main:
>
> lea eax, [rdi+208+rdi*2]
>
> ret
>
>
>
>
>
> As you can see the “if” condition has the same calculation for both the
> “if” and “else” branch in calculating the sum over the array, however, it
> seems that it is triggering the “loop splitting pass” which results in
> further optimizations such as constant folding of the whole computation and
> resulting in such a smaller and faster assembly code.
>
> My question is, why the compiler is not able to take advantage of
> constantans in the prefix of the array in the first place?
>
> Also adding a not necessary “if condition” which is just repeating the same
> code for "if" and "else", doesn’t seem to be the best way to hint the
> compiler to take advantage of this optimization; so is there another way to
> make the compiler aware of this? ( I used the -fsplit-loops flag and it
> didn't have any effect for this example.)
>
>
>
> As a next step if we use an array that has some constant values in the
> prefix but not a compile time constant length such as the following example:
>
> Code link is here: https://godbolt.org/z/3qGqshzn9
>
>
>
> #include
>
> inline int sum(const int array[], size_t len) {
>
> int res = 0;
>
> for (size_t i = 0; i < len; i++) {
>
> if (i < 1)
>
> res += array[i];
>
> else
>
> res += array[i];
>
> }
>
> return res;
>
> }
>
> int main(int argc, char** argv)
>
> {
>
> size_t len = argc+3;
>
> int arr3[len] = {600,10,1};
>
> for (unsigned int i = 3; i < len; i++) arr3[i] = argc+i;
>
> return sum(arr3, 2);
>
> }
>
>
>
> In this case the GCC compiler is not able to apply constant folding on the
> first part of the array!
>
> In general is there anyway that the GCC compiler would understand this and
> apply constant folding optimizations here?
GCC can currently only constant fold this when it decides to unroll the
loop portions operating in constant data.
Richard.
