在 2024/11/27 下午3:10, Xi Ruoyao 写道:
On Wed, 2024-11-27 at 14:24 +0800, Lulu Cheng wrote:
在 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,
Hmm, as the test case is directly invoking __builtin_lsx_*, there's no
undefined behavior.
OTOH if "x" is a v16i8, "x <<= 9" will invoke an undefined behavior as
documented in https://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html.
do we want to ensure that the behavior is consistent before and after
the change?
The behavior is already inconsistent: before the change it even won't
assemble :).
I guess you mean we should ensure the result same as loading the shift
amount into a vector register and using the vsll.b instruction (instead
of optimizing into a vslli.b instruction)?
That's what I mean.:-D
If we want to be consistent, I think it's still necessary to detect the
generated assembly sequence.
Then OK. Note that we'd need { dg-options -save-temps } if running
scan-assembler on a { dg-do assemble } test.
