[BUG] Stack spill in broadcast_lane (shufflev2) on SVE/2

[SadiinsoSnowfall]

Codegen for has_equal_in on a pair of u16x4 (GCC15, SVE2-256):

test(eve::arm_sve256_v0::wide<unsigned short, eve::fixed<4l>>, eve::arm_sve256_v0::wide<unsigned short, eve::fixed<4l>>):
        sub     sp, sp, #720
        ptrue   p3.b, vl32
        mov     z3.d, d1
        add     x0, sp, 288
        st1h    z3.h, p3, [x0]
        ptrue   p0.h, vl4
        add     x0, sp, 672
        ldp     q30, q31, [sp, 288]
        stp     q30, q31, [sp, 672]
        ld1h    z2.h, p3/z, [x0]
        add     x0, sp, 432
        st1h    z2.h, p3, [x0]
        add     x0, sp, 672
        ldp     q30, q31, [sp, 432]
        stp     q30, q31, [sp, 672]
        ld1h    z1.h, p3/z, [x0]
        match   p0.h, p0/z, z0.h, z1.h
        add     sp, sp, 720
        ret

same thing but replacing the call to broadcast_lane with a call to shuffle (v1):

test(eve::arm_sve256_v0::wide<unsigned short, eve::fixed<4l>>, eve::arm_sve256_v0::wide<unsigned short, eve::fixed<4l>>):
        mov     z1.d, d1
        ptrue   p0.h, vl4
        match   p0.h, p0/z, z0.h, z1.h
        ret

Might be related to tuple manipulation again

[DenisYaroshevskiy]

sve128 is fine: https://godbolt.org/z/a3MfhYjPa

Here is a 4 element https://godbolt.org/z/WbhYcos94

[DenisYaroshevskiy]

sve256: partial reproduced https://godbolt.org/z/Mq59cn1Ma

[DenisYaroshevskiy]

@SadiinsoSnowfall - do you remember what we did last time?

[SadiinsoSnowfall]

has_equal_in on SVE-128 with a full vector is fine because it's the case where we can perform the op in one go without any shuffling.
It is still kinda weird that the bc itself only works well on SVE-128. https://godbolt.org/z/66GEnehKa (comparison with manual bcast).

I don't exactly remember, I think we always had problems like this with shufflev2 on SVE. But now that every kumi function seems to be correctly marked as forceinline/flatten I'm not sure where the problem is coming from. SVE registers might get too big for GCC to handle properly ? That would also explain why the codegen worsen with the increasing vector size.

[SadiinsoSnowfall]

The bcast works well at any vector size on clang 21+ (not surprising since they seem to have put a lot of effort into their SVE backend lately). This means that we will soon only have this problem on GCC.