在 2024/11/27 下午12:06, Xi Ruoyao 写道:
On Wed, 2024-11-27 at 11:58 +0800, Lulu Cheng wrote:
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/vector/lasx/lasx-shift-sameimm-vec.c
@@ -0,0 +1,72 @@
+/* Test shift bits overflow in vector */
+/* { dg-do compile } */
+/* { dg-options "-mlasx -O2" } */
+/* { dg-final { scan-assembler "xvslli.b.*,1" } } */
Am I correct that the issue has triggered an assembler error? IIUC we
can change it to "dg-do assemble" and then we don't need to have all
those scan-assembler.
Without adding this patch, the following builtin function can be
successfully compiled, generating "vslli.b$vr 0,$vr 0,9",
"9" is outside the immediate range of uimm3.:-
eg :__builtin_lsx_vsll_b(_, (v16i8) {9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9,
9, 9, 9, 9});
Yes I understand that, I mean:
$ ./gcc/xgcc -B gcc t.c
/tmp/ccjhHz0k.s: Assembler messages:
/tmp/ccjhHz0k.s:16: Fatal error: Immediate overflow.
format: u10:3
arg: 9
So we can use
/* { dg-do assemble } */
instead of
/* { dg-do compile } */
and then if the issue wasn't fixed we'd get an assembler error, thus we
no longer need write many scan-assembler directives to check if the
issue is fixed.
I also think it's better to use "dg-do assemble" than "dg-do compile" here.
But I still have a question, although this behavior of these test cases
is undefined in the C standard,
do we want to ensure that the behavior is consistent before and after
the change?
If we want to be consistent, I think it's still necessary to detect the
generated assembly sequence.
