[BUG][Clang][AArch64] LLVM backend error: Invalid size request on a scalable vector.

[toor1245]

The Clang compiler, LLVM reports error "fatal error: error in backend: Invalid size request on a scalable vector." starting from version 17.0.1 with the following compiler options:

-march=armv9-a and higher (armv9.1-a, armv9.2-a, armv9.3-a and so on) and -mstrict-align and optimization flags like -Os, -O2

Notes when it works successfully:

• When Optimization flag: -O0, -O1, -O3, example https://gcc.godbolt.org/z/4ojzoz9jP
• Without -mstrict-align flag, example https://gcc.godbolt.org/z/7MbqGfoe8
• Without any optimization flags and specified -mstrict-align with -march=armv9-a, example https://gcc.godbolt.org/z/e7q1bv498
• When target architecture from armv8-a to armv8.9-a, example https://gcc.godbolt.org/z/q6eobPPPx
• When loop iteration count not power of 2, for example, array_size is 127 - https://gcc.godbolt.org/z/d7rKvdboG

armv8-a clang (trunk) - Failed

• https://gcc.godbolt.org/z/9r5Mva8oe

armv8-a clang 18.1.0 - Failed

• https://gcc.godbolt.org/z/747e3hd7h

armv8-a clang 17.0.1 - Failed

• https://gcc.godbolt.org/z/zMW4hWGhW

armv8-a clang 16.0.0 - No problem

• https://gcc.godbolt.org/z/nr9a9EhM5

Steps to reproduce the issue.

#include <stdint.h>
#include <stdlib.h>

uint64_t *InvalidSizeRequestOnScalableVector()
{
    uint64_t value = 30;
    uint64_t array_size = 128;
    uint64_t *array = (uint64_t *) malloc(sizeof(uint64_t) * array_size);

    for (unsigned long i = 0; i < array_size; i++)
    {
        array[i] = value;
    }

    return array;
}

[llvmbot]

@llvm/issue-subscribers-backend-aarch64

Author: Mykola Hohsadze (toor1245)

The Clang compiler, LLVM reports error "fatal error: error in backend: Invalid size request on a scalable vector." starting from version 17.0.1 with the following compiler options:

-march=armv9-a and higher (armv9.1-a, armv9.2-a, armv9.3-a and so on) and -mstrict-align and optimization flags like -Os, -O2

Notes when it works successfully:

• When Optimization flag: -O0, -O1, -O3, example https://gcc.godbolt.org/z/4ojzoz9jP
• Without -mstrict-align flag, example https://gcc.godbolt.org/z/7MbqGfoe8
• Without any optimization flags and specified -mstrict-align with -march=armv9-a, example https://gcc.godbolt.org/z/e7q1bv498
• When target architecture from armv8-a to armv8.9-a, example https://gcc.godbolt.org/z/q6eobPPPx
• When loop iteration count not power of 2, for example, array_size is 127 - https://gcc.godbolt.org/z/d7rKvdboG

armv8-a clang (trunk) - Failed

• https://gcc.godbolt.org/z/9r5Mva8oe

armv8-a clang 18.1.0 - Failed

• https://gcc.godbolt.org/z/747e3hd7h

armv8-a clang 17.0.1 - Failed

• https://gcc.godbolt.org/z/zMW4hWGhW

armv8-a clang 16.0.0 - No problem

• https://gcc.godbolt.org/z/nr9a9EhM5

Steps to reproduce the issue.

#include <stdint.h>
#include <stdlib.h>

uint64_t *InvalidSizeRequestOnScalableVector()
{
    uint64_t value = 30;
    uint64_t array_size = 128;
    uint64_t *array = (uint64_t *) malloc(sizeof(uint64_t) * array_size);

    for (unsigned long i = 0; i < array_size; i++)
    {
        array[i] = value;
    }

    return array;
}

[davemgreen]

I don't believe we need to scalarize scalable vectors with natural element-sizes. (I may be mistaken, the pseudo code is not super clear in this regard).

[tgymnich]

I noticed that when the array_size is not statically known we emit a masked_store instead of a store.
However the -mstrict-align checks do not seem to be applied to masked stores.
When trying to expand a normal store of a scalable vector with -mstrict-align we crash because expandUnalignedStore does not expect scalable vectors.

[brad0]

@toor1245 It looks like this has been resolved as of 20 or newer.

[toor1245]

@brad0, checked failed cases in godbolt for 20 version, don't see any backend errors.

Questions for llvm community:

• Is it known which commit/issue fixed this issue? It may be useful to fix Clang compiler versions before ver. 20.
• Will the fix be added to previous versions?

[DavidSpickett]

I bisected this to 3b17d04, which was first in a release of 20.1.0:

$ git bisect good
3b17d041dd775e033cca499f2a25548c8c22bb86 is the first bad commit
commit 3b17d041dd775e033cca499f2a25548c8c22bb86
Author: Benjamin Maxwell <benjamin.maxwell@arm.com>
Date:   Mon Dec 16 10:23:40 2024 +0000

    [AArch64][SVE] Don't require 16-byte aligned SVE loads/stores with +strict-align (#119732)

(where good means we have the bug, bad means we do not, it's inverted)

My reproducer was:

./bin/clang --target=aarch64-linux-gnu -march=armv9-a -mstrict-align -O2 /tmp/test.c -o /dev/null

Please check the other combinations you mentioned in the initial report, just to be sure the fix applies to them all.

Branches other than the current release branch do not get backports (https://llvm.org/docs/HowToReleaseLLVM.html#annual-release-schedule, though it does not spell that out exactly, that's the effect of that schedule).

Even if we did backport it to the 19.x branch, we would have to have everyone build a whole new release package for a new 19.whatever. Which is a very high bar to meet.

If you are building based on older branches, the commit could be cherry picked. It doesn't seem like one of a series of commits, just this one. @MacDue correct me if I'm wrong about that.

[brad0]

@DavidSpickett Thanks! That applied to 19 fixes building the reproducer as well as the SVE code I was trying to build (aom / SVT-AV1) and ran into the same error message.

[DavidSpickett]

I'm no codegen expert, so @davemgreen do you think there is anything left to do for this issue or can we close it?

[MacDue]

My patch fixes the case where the load/store is correctly aligned to the element size (which fixes cases where the vectors come from the vectorizer). The underlying issue (that we can't expand unaligned SVE loads) is still there, the second test in 3b17d04 is an XFAIL one for that issue (though I don't think such loads/stores would ever be generated by the compiler).