Re: [PATCH 3/3] tests/tcg/s390x: Test VSTRS

[Ilya Leoshkevich <iii@linux.ibm.com>]

On Sun, 2023-08-06 at 13:05 +0200, Claudio Fontana wrote:
> On 8/5/23 01:03, Ilya Leoshkevich wrote:
> > Add a small test to prevent regressions.
> > 
> > Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
> > ---
> >  tests/tcg/s390x/Makefile.target |  1 +
> >  tests/tcg/s390x/vxeh2_vstrs.c   | 88
> > +++++++++++++++++++++++++++++++++
> >  2 files changed, 89 insertions(+)
> >  create mode 100644 tests/tcg/s390x/vxeh2_vstrs.c
> > 
> > diff --git a/tests/tcg/s390x/Makefile.target
> > b/tests/tcg/s390x/Makefile.target
> > index 1fc98099070..8ba36e5985b 100644
> > --- a/tests/tcg/s390x/Makefile.target
> > +++ b/tests/tcg/s390x/Makefile.target
> > @@ -73,6 +73,7 @@ ifneq ($(CROSS_CC_HAS_Z15),)
> >  Z15_TESTS=vxeh2_vs
> >  Z15_TESTS+=vxeh2_vcvt
> >  Z15_TESTS+=vxeh2_vlstr
> > +Z15_TESTS+=vxeh2_vstrs
> >  $(Z15_TESTS): CFLAGS+=-march=z15 -O2
> >  TESTS+=$(Z15_TESTS)
> >  endif
> > diff --git a/tests/tcg/s390x/vxeh2_vstrs.c
> > b/tests/tcg/s390x/vxeh2_vstrs.c
> > new file mode 100644
> > index 00000000000..313ec1d728f
> > --- /dev/null
> > +++ b/tests/tcg/s390x/vxeh2_vstrs.c
> > @@ -0,0 +1,88 @@
> > +/*
> > + * Test the VSTRS instruction.
> > + *
> > + * SPDX-License-Identifier: GPL-2.0-or-later
> > + */
> > +#include <assert.h>
> > +#include <stdint.h>
> > +#include <stdio.h>
> > +#include <stdlib.h>
> > +#include "vx.h"
> > +
> > +static inline __attribute__((__always_inline__)) int
> > +vstrs(S390Vector *v1, const S390Vector *v2, const S390Vector *v3,
> > +      const S390Vector *v4, const uint8_t m5, const uint8_t m6)
> > +{
> > +    int cc;
> > +
> > +    asm("vstrs %[v1],%[v2],%[v3],%[v4],%[m5],%[m6]\n"
> > +        "ipm %[cc]"
> > +        : [v1] "=v" (v1->v)
> > +        , [cc] "=r" (cc)
> > +        : [v2] "v" (v2->v)
> > +        , [v3] "v" (v3->v)
> > +        , [v4] "v" (v4->v)
> > +        , [m5] "i" (m5)
> > +        , [m6]  "i" (m6)
> > +        : "cc");
> > +
> > +    return (cc >> 28) & 3;
> Following the POp, I am puzzled by the use of an "int" to contain the
> register result of the IPM instruction, should it not be a 64bit
> variable?
> bits 0-31 are left unchanged / are uninteresting, is that enough to
> avoid having to use a properly sized variable?

The compiler understands that if the type is int, then the asm block
will not touch the upper 32 bits of the register that's assigned to it.
This observation is used not only in the QEMU tests, but also all over
arch/s390 in the Linux kernel.

> 
> I see that this is done elsewhere in the tests (sometimes a 64bit
> variable is used, sometimes just 'int'), so I assume it's probably
> fine.
> 
> Otherwise lgtm,
> 
> Claudio

[...]
>