[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 3/3] tests/tcg/s390x: test signed vfmin/vfmax
From: |
Ilya Leoshkevich |
Subject: |
Re: [PATCH 3/3] tests/tcg/s390x: test signed vfmin/vfmax |
Date: |
Wed, 13 Jul 2022 18:14:41 +0200 |
User-agent: |
Evolution 3.42.4 (3.42.4-2.fc35) |
On Wed, 2022-07-13 at 21:14 +0530, Richard Henderson wrote:
> On 7/12/22 18:02, Ilya Leoshkevich wrote:
> > > This works, of course. It could be simpler using EXECUTE, to
> > > store
> > > just the one
> > > instruction and not worry about an executable mapped page, but I
> > > guess it doesn't matter.
> >
> > I thought about this too, but EX/EXRL operate only on the second
> > byte,
> > and I need to modify bytes 3-5 here.
>
> I didn't mean modify the instruction via EX, but something like
>
> static char minmax[6] __attribute__((aligned(2)))
> = { xx, yy, zz, 0, 0, 0 };
>
> minmax[3] = m6 ...
> minmax[4] = ...
> minmax[5] = op;
>
> asm("vl %%v25,0(%1)\n"
> "vl %%v26,0(%2)\n"
> "ex 0,0(%3)\n"
> "vst %%v24,0(%0)"
> : : "a"(v1), "a"(v2), "a"(v3), "a"(minmax)
> : "memory", "v24", "v25", "v26);
>
>
> r~
Nice trick!
This works in qemu, but not natively: EX target must be executable.
I'd still like to try to find a way to establish an rwx section, and
send a v2 with this improvement.
I guess we'll need to fix the access check discrepancy some day.
- [PATCH 1/3] target/s390x: fix handling of zeroes in vfmin/vfmax, (continued)