[clang][LoongArch] LSX/LASX headers do not work with -fno-lax-vector-conversions

[xen0n]

The current Clang LSX/LASX intrinsics header files make heavy use of implicit vector conversions vector bitcasts, that is not accepted by Clang 18+ (Clang 17 does not support Loongson SIMD) with -fno-lax-vector-conversions. Example:

// clang -c -fno-lax-vector-conversions -mlsx test-lsx-lax-conversion.c
#include <lsxintrin.h>
int main(void) { return 0; }

In file included from test-lsx-lax-conversion.c:1:
/usr/lib/llvm/19/bin/../../../../lib/clang/19/include/lsxintrin.h:42:40: error: cannot initialize a parameter of type '__attribute__((__vector_size__(16 * sizeof(char)))) char' (vector of 16 'char' values) with an rvalue of type 'v16i8' (vector of 16 'signed char' values)
   42 |   return (__m128i)__builtin_lsx_vsll_b((v16i8)_1, (v16i8)_2);
      |                                        ^~~~~~~~~
[lots of similar errors omitted]

It complicates distribution packaging for certain software, because

1. they require or work better with Clang, and
2. effectively one is forced to enable -flax-vector-conversions here and there, for example Skia.

So it may be best to just fix the headers to work with strict vector conversion checks, to stop the proliferation of lax coding practice.

[xen0n]

Sketch: https://godbolt.org/z/s94GWb3fs

Sketch code

// compile with: -O1 -mlsx -fno-lax-vector-conversions
// for Clang, add --target=loongarch64 if not natively experimenting

#ifdef __clang__
// #include <lsxintrin.h>
typedef signed char v16i8 __attribute__((vector_size(16), aligned(16)));
typedef long long __m128i __attribute__((__vector_size__(16), __may_alias__));

// clang distinguishes between "signed char" and "char"
// __builtin_lsx_vsll_b is defined with the following:
//
//     TARGET_BUILTIN(__builtin_lsx_vsll_b, "V16cV16cV16c", "nc", "lsx")
//
// so it doesn't accept "signed char" vectors
// (each "V16c" would have to become "V16Sc" for "signed char")
//
// kludge without modifying Clang: provide a v16i8 defined with bare "char"
typedef char v16c8 __attribute__((vector_size(16), aligned(16)));
#else
#include <lsxintrin.h>
typedef v16i8 v16c8;
#endif

__m128i __lsx_vsll_b_xxx(__m128i _1, __m128i _2) {
  // return (__m128i)__builtin_lsx_vsll_b((v16i8)_1, (v16i8)_2);
  return (__m128i)__builtin_lsx_vsll_b((v16c8)_1, (v16c8)_2);
}

We probably have to provide a bare char variant of v16i8, or amend the signature of possibly many builtins involving chars to have signedness always explicitly spelled out.

[xen0n]

CC-ing people for better visibility, this is best handled ASAP because toolchain changes can take a long time to propagate to distros:

cc @ChenghuaXu @chenglulu326 @SixWeining @heiher @xry111 (toolchain)
cc @KexyBiscuit @wszqkzqk (packagers)
cc @double1Kai (LoongArch skia)

[xry111]

AFAIK removing "signed" is not an option because it'll cause stupid things if someone uses -funsigned-char.

[xry111]

Thus the correct thing to do is fixing clang builtin to accept a signed char vector.

[wangleiat]

Thus the correct thing to do is fixing clang builtin to accept a signed char vector.

I completely agree with your point.

[xen0n]

Previously I worried about compatibility of signatures of the builtins, but @xry111 told me yesterday that the public API surface is the intrinsic header and not the builtins. And with the immediate errors on the inclusion of the header, there's no previously-working code that would be regressed by the signature change either.

So I would also agree that amending the builtins' signatures is the best way forward.

[xen0n]

@SixWeining @xry111 -- Thanks for the fix and quick review & merge; I think it may also be appropriate to backport this patchset to LLVM 19.x because this would allow downstream to drop their kludges 6 months earlier.

(We have to act quick though, LLVM 19.1.4 is slated for Nov 12th i.e. a week from now. I cannot help this time due to very tight schedule though.)

[SixWeining]

@SixWeining @xry111 -- Thanks for the fix and quick review & merge; I think it may also be appropriate to backport this patchset to LLVM 19.x because this would allow downstream to drop their kludges 6 months earlier.

Yes, I think so.

[SixWeining]

/cherry-pick 96d2196 b885054 92daad2 4006b28 4f740f9

[llvmbot]

/pull-request #114958