On 2020/7/14 10:59, Frank Chang wrote:
On Sat, Jul 11, 2020 at 12:27 AM Richard Henderson
<[email protected] <mailto:[email protected]>>
wrote:
On 7/10/20 3:48 AM, [email protected]
<mailto:[email protected]> wrote:
> From: Frank Chang <[email protected]
<mailto:[email protected]>>
>
> vsll.vi <http://vsll.vi>, vsrl.vi <http://vsrl.vi>, vsra.vi
<http://vsra.vi> cannot use shli gvec as it requires the
> shift immediate value to be within the range: [0.. SEW bits].
> Otherwise, it will hit the assertion:
> tcg_debug_assert(shift >= 0 && shift < (8 << vece));
>
> However, RVV spec does not have such constraint, therefore we
have to
> use helper functions instead.
Why do you say that? It does have such a constraint:
# Only the low lg2(SEW) bits are read to obtain the shift amount
from a
register value.
While that only talks about the register value, I sincerely doubt
that the same
truncation does not actually apply to immediates.
And if the entire immediate value does apply, the manual should
certainly
specify what should happen in that case. And at present it doesn't.
It seems to me the bug is the bare use of GEN_OPIVI_GVEC_TRANS and
thence
do_opivi_gvec. The ZX parameter should be extended to more than
just "zero vs
sign-extend", it should have an option for truncating the
immediate to s->sew.
r~
The latest spec specified:
Only the low *lg2(SEW) bits* are read to obtain the shift amount from
a *register value*.
The *immediate* is treated as an *unsigned shift amount*, with a
*maximum shift amount of 31*.
Looks like the shift amount in the immediate value is not relevant
with SEW setting.
If so, is it better to just use do_opivi_gvec() and implement the
logic by our own rather than using gvec IR?
In my opinion, it doesn't matter to truncate the immediate to s->sew
before calling the gvec IR,
whether the constraint of immediate exits or not.
Zhiwei
Frank Chang
