Why does g++ not optimize a local array but a global?

Question

I have the following two functions which do basically the same:

enum Direction{
    N = 0,
    NW,
    W,
    SW,
    S,
    SE,
    E,
    NE,
    TOTAL_DIRS
};

char const * const strings[] = {"N", "NW", "W", "SW", "S", "SE", "E", "NE"};

char const *
getDirString2(unsigned dir) {
    if (TOTAL_DIRS > dir)
        return strings[dir];
    return nullptr;
}

char const *
getDirString3(unsigned dir) {
    char const * const strings[] = {"N", "NW", "W", "SW", "S", "SE", "E", "NE"};
    if (TOTAL_DIRS > dir)
        return strings[dir];
    return nullptr;
}

But while g++ optimizes the function which uses the global array like I would expect. It creates much more, convoluted code for the alternative. Clang creates the same code for both and if I use a switch-statement instead, both clang and c++ also create the same code as for getDirString2.

Here is a link to compiler explorer https://godbolt.org/z/GxvrTv

Is this something for which I should file a bug report for g++ or is there a good reason for that?

Answer 1

I guess you could call this a missed optimisation, although that's a bit harsh on the gcc guys.

gcc, when compiling getDirString3, is doing exactly what you asked it to do - construct an array of strings on the stack and then return just one element of it.

clang, on the other hand, sees that this array never changes and constructs it in static storage instead, see: https://godbolt.org/z/24n-N7

To make gcc generate code like clang does, declare the array inside getDirString3 as static (which would have been a good idea in the first place), see: https://godbolt.org/z/henD2Z

Answer 2

Note: At first, I said that this is a non-conforming optimization, but after my discussion with Chris Dodd in the comments, I realized that this is partially incorrect.

The Updated Answer:

Is this something for which I should file a bug report for g++ or is there a good reason for that?

Both clang and gcc can do the same optimization, but it's disabled in gcc by default. So it's not a bug, and there's a reason for it.

What did clang do?

In your example, the compiler saw that the local array is constant and as a result there's no need to construct it on the stack each time the function is invoked.

How to enable the same optimization in gcc?

To enable the same optimization in gcc, use the the flag -fmerge-all-constants. The resultant code will be almost the same size as clang's code (see: https://godbolt.org/z/Ldx_qe):

getDirString3(unsigned int):
        xor     eax, eax
        cmp     edi, 7
        ja      .L1
        mov     edi, edi
        mov     rax, QWORD PTR strings.2080[0+rdi*8]

Why it's disabled by default in gcc?

From gcc documentation website:

-fmerge-all-constants ... Languages like C or C++ require each variable, including multiple instances of the same variable in recursive calls, to have distinct locations, so using this option results in non-conforming behavior.

In the above example the optimization was safe and followed the as-if rule, because the address of this local array wasn't used or compared with an address from different invocation. However, it seems that this optimization can lead in some cases to non-confroming behavior. You can check these cases: here and here.

So, should you use the -fnmerge-all-constants flag?

Both compilers don't check weather the address of the constants is used or not, therefore I don't recommend it. It's obvious in your example that the optimization is safe, but you can't know every time where youre compiler will optimize (or else you would've done it yourself) and you can't be sure that it won't lead sometimes to non-confroming behavior.