Re: Why does this unrolled function write to the stack?

[David Brown <david@westcontrol.com>]

On 08/02/2023 14:53, Jonathan Wakely via Gcc-help wrote:
> On Wed, 8 Feb 2023 at 13:49, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>>
>> On Wed, 8 Feb 2023 at 13:31, Gaelan Steele via Gcc-help
>> <gcc-help@gcc.gnu.org> wrote:
>>>
>>> Hi all,
>>>
>>> In a computer architecture class, we happened across a strange compilation choice by GCC that neither I nor my professor can make much sense of. The source is as follows:
>>>
>>> void foo(int *a, const int *__restrict b, const int *__restrict c)
>>> {
>>>    for (int i = 0; i < 16; i++) {
>>>      a[i] = b[i] + c[i];
>>>    }
>>> }
>>>
>>> I won't reproduce the full compiled output here, as it's rather long, but when compiled with -O3 -mno-avx -mno-sse, GCC 12.2 for x86-64 (via Compiler Explorer: https://godbolt.org/z/o9e4o7cj4) produces an unrolled loop that appears to write each sum into an array on the stack before copying it into the provided pointer a. This seems hugely inefficient - it's doing quite a few memory accesses - and I can't see why it would be necessary.
>>
>> I don't think it's *necessary*. If you use -Os or -O1 or -O2 you get a
>> loop. So it's just an optimization choice at -O3 presumably based on
>> cost estimates that say that fully unrolling the loop will make the
>> code faster than looping.
>>

There's nothing wrong with the loop unrolling.  It's the use of space on 
the stack that's the problem.

> So it does look like GCC is making poor choices here.
> 

It seems to be a regression between gcc 10 and gcc 11 (discovered by 
changing the compiler on godbolt.org).  With gcc 11 onwards, the 
compiler seems to be using the stack to combine two 4-byte elements at a 
time into a single 8-byte element.  It's easy to see the effect by 
changing the loop size to 2.

(I've no idea what causes the effect, or how to fix it - but knowing it 
is a regression might make it easier for you to find.)