xtheadvector intrinsic tail undisturbed policy does not work

[nihui]

Xuantie-900-gcc-linux-6.6.0-glibc-x86_64-V3.0.1
Xuantie-qemu-x86_64-Ubuntu-20.04-V5.0.4-B20241127-1130

riscv64-unknown-linux-gnu-gcc -march=rv64gc_zfh_xtheadvector -mabi=lp64d -static tu.c -o tu -O2
qemu-riscv64 -cpu c906fdv ./tu

wrong output (should be -999 for tail elements)

-20.00 -4.00 -10.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

---

compiling for c908v with rvv-1.0 works fine, using the same compiler and qemu

riscv64-unknown-linux-gnu-gcc -march=rv64gcv_zfh_zvfh -mabi=lp64d -static tu.c -o tu-v -O2
qemu-riscv64 -cpu c908v ./tu-v

expected output

-20.00 -4.00 -10.00 -999.00 -999.00 -999.00 -999.00 -999.00 -999.00 -999.00 -999.00 -999.00 -999.00 -999.00 -999.00 -999.00 -999.00 -999.00 -999.00 -999.00 -999.00 -999.00 -999.00 -999.00 -999.00 -999.00 -999.00 -999.00 -999.00 -999.00 -999.00 -999.00 

---

This issue can also be reproduced using upstream gcc without xtheadc extension

gcc git commit 7efe3aa9b5d4d7aba3736d1393b007705522dc45

---

minimal test

// riscv64-unknown-linux-gnu-gcc -march=rv64gc_zfh_xtheadvector -mabi=lp64d -static tu.c -o tu -O2
// qemu-riscv64 -cpu c906fdv ./tu

#include <riscv_vector.h>
#include <stdio.h>

int main()
{
    // _max contains all -999
    vfloat32m8_t _max = __riscv_vfmv_v_f_f32m8(-999, __riscv_vsetvlmax_e32m8());

    float tmp[3] = {-20, -4, -10};
    size_t vl = 3;

    vfloat32m8_t _p = __riscv_vle32_v_f32m8(tmp, vl);

    _max = __riscv_vfmax_vv_f32m8_tu(_max, _max, _p, vl);

    // _max should contains -20, -4, -10, -999, -999, .....
    // but on xtheadvector  -20, -4, -10, 0, 0, ....
    // tu policy seems not working here

    // debug print
    {
        // assume 128bit rvv
        float tmp[32];
        __riscv_vse32_v_f32m8(tmp, _max, __riscv_vsetvlmax_e32m8());

        for (int i = 0; i < 32; i++)
        {
            fprintf(stderr, "%.2f ", tmp[i]);
        }
        fprintf(stderr, "\n");
    }

    return 0;
}

[majin2020]

Hello, I'm truly sorry for the inconvenience you're experiencing. Unfortunately, XTheadVector doesn't have a concept of tail undisturbed policy. Therefore, it can only generate a default approach, similar to how RVV 1.0's vm=1 and vta=1 operate.

[nihui]

Hello, I'm truly sorry for the inconvenience you're experiencing. Unfortunately, XTheadVector doesn't have a concept of tail undisturbed policy. Therefore, it can only generate a default approach, similar to how RVV 1.0's vm=1 and vta=1 operate.

Understand
Should the compiler handle this situation automatically, such as inserting mask and merge operations, or directly let it fail to compile and warn the user
What is the best practice here? In RVV, tu policy is usually used to implement calculations such as variant lengthed array sum or reduction

[nihui]

Hello, I'm truly sorry for the inconvenience you're experiencing. Unfortunately, XTheadVector doesn't have a concept of tail undisturbed policy. Therefore, it can only generate a default approach, similar to how RVV 1.0's vm=1 and vta=1 operate.

my__riscv_vfmax_vv_f32m8_tu for xtheadvector workaround

// riscv64-unknown-linux-gnu-gcc -march=rv64gc_zfh_xtheadvector -mabi=lp64d -static tu.c -o tu -O2
// qemu-riscv64 -cpu c906fdv ./tu

#include <riscv_vector.h>
#include <stdio.h>

vfloat32m8_t my__riscv_vfmax_vv_f32m8_tu(vfloat32m8_t a, vfloat32m8_t b, vfloat32m8_t c, size_t vl)
{
#if __riscv_xtheadvector
    const size_t vlm8 = __riscv_vsetvlmax_e32m8();
    vbool4_t _vl_mask = __riscv_vmsgeu_vx_u32m8_b4(__riscv_vid_v_u32m8(vlm8), vl, vlm8);
    vfloat32m8_t c_masked = __riscv_vmerge_vvm_f32m8(c, a, _vl_mask, vlm8);
    return __riscv_vfmax_vv_f32m8(b, c_masked, vlm8);
#else
    return __riscv_vfmax_vv_f32m8_tu(a, b, c, vl);
#endif
}

int main()
{
    // _max contains all -999
    vfloat32m8_t _max = __riscv_vfmv_v_f_f32m8(-999, __riscv_vsetvlmax_e32m8());

    float tmp[3] = {-20, -4, -10};
    size_t vl = 3;

    vfloat32m8_t _p = __riscv_vle32_v_f32m8(tmp, vl);

    // _max = __riscv_vfmax_vv_f32m8_tu(_max, _max, _p, vl);

    // HACK here
    _max = my__riscv_vfmax_vv_f32m8_tu(_max, _max, _p, vl);

    // _max should contains -20, -4, -10, -999, -999, .....
    // but on xtheadvector  -20, -4, -10, 0, 0, ....
    // tu policy seems not working here

    // debug print
    {
        // assume 128bit rvv
        float tmp[32];
        __riscv_vse32_v_f32m8(tmp, _max, __riscv_vsetvlmax_e32m8());

        for (int i = 0; i < 32; i++)
        {
            fprintf(stderr, "%.2f ", tmp[i]);
        }
        fprintf(stderr, "\n");
    }

    return 0;
}

[majin2020]

Hello, I'm truly sorry for the inconvenience you're experiencing. Unfortunately, XTheadVector doesn't have a concept of tail undisturbed policy. Therefore, it can only generate a default approach, similar to how RVV 1.0's vm=1 and vta=1 operate.

Understand Should the compiler handle this situation automatically, such as inserting mask and merge operations, or directly let it fail to compile and warn the user What is the best practice here? In RVV, tu policy is usually used to implement calculations such as variant lengthed array sum or reduction

Due to specification limitations, similar operations can only be accomplished using the merge operation, just as you have done :）

[nihui]

Hello, I'm truly sorry for the inconvenience you're experiencing. Unfortunately, XTheadVector doesn't have a concept of tail undisturbed policy. Therefore, it can only generate a default approach, similar to how RVV 1.0's vm=1 and vta=1 operate.

Understand Should the compiler handle this situation automatically, such as inserting mask and merge operations, or directly let it fail to compile and warn the user What is the best practice here? In RVV, tu policy is usually used to implement calculations such as variant lengthed array sum or reduction

Due to specification limitations, similar operations can only be accomplished using the merge operation, just as you have done :）

yeah, but is there any news of updated toolchain on https://www.xrvm.cn/community/download ?
V3.0.1 is old and has known fp16 bug