AArch64: Missed post-increment opportunity

[MatzeB]

Repro:

#include <arm_neon.h>
void partialWrite(uint8_t* p, uint16x8_t vec) {
    vst1q_lane_u16(reinterpret_cast<uint16_t*>(p), vec, 0);
    vst1q_lane_u8(p + 2, vreinterpretq_u8_u16(vec), 2);
}

Currently produces:

$ clang++ -target aarch64-redhat-linux-gnu -march=armv9-a+sve2+fp16 repro.cpp
...
       add     x8, x0, #2
        str     h0, [x0]
        st1     { v0.b }[2], [x8]
        ret

misses the opportunity to use post-increment on the first str Could be the following (as produced by GCC):

       str     h0, [x0], 2
       st1     {v0.b}[2], [x0]
       ret

(this mirrors meta T222168293 )

[llvmbot]

@llvm/issue-subscribers-backend-aarch64

Author: Matthias Braun (MatzeB)

Repro: ``` #include <arm_neon.h> void partialWrite(uint8_t* p, uint16x8_t vec) { vst1q_lane_u16(reinterpret_cast<uint16_t*>(p), vec, 0); vst1q_lane_u8(p + 2, vreinterpretq_u8_u16(vec), 2); } ``` Currently produces: ``` $ clang++ -target aarch64-redhat-linux-gnu -march=armv9-a+sve2+fp16 repro.cpp ... add x8, x0, #2 str h0, [x0] st1 { v0.b }[2], [x8] ret ``` misses the opportunity to use post-increment on the first str Could be the following (as produced by GCC): ``` str h0, [x0], 2 st1 {v0.b}[2], [x0] ret ```

(this mirrors meta T222168293 )

[davemgreen]

We now generate https://godbolt.org/z/3a7hb1o5P

partialWrite(unsigned char*, __Uint16x8_t):
        mov     b1, v0.b[2]
        str     h0, [x0]
        stur    b1, [x0, #2]
        ret

That is different still (at least in this small example). It may be better even if it is not smaller due to the free address increment, not needing an extra uop for the postinc. (For V2, although I am not sure it is fully correct: https://godbolt.org/z/EaPqxv3xe)

[MatzeB]

Was already wondering whether the postincrement may hurt ILP. Good to see this played out explicitely in llvm-mca! So nothing to do here when targetting cores like Neoverse V2.