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)?
> 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.
--
Xi Ruoyao <[email protected]>
School of Aerospace Science and Technology, Xidian University
