On 7/10/20 3:48 AM, email@example.com wrote:
> From: Frank Chang <firstname.lastname@example.org>
> vsll.vi, vsrl.vi, vsra.vi cannot use shli gvec as
it requires the
> shift immediate value to be within the range: [0.. SEW
> Otherwise, it will hit the assertion:
> tcg_debug_assert(shift >= 0 && shift < (8
> 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
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
specify what should happen in that case. And at present it
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.
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?