On Sat, Jul 11, 2020 at 12:27 AM Richard Henderson < [email protected]> wrote:
> On 7/10/20 3:48 AM, [email protected] wrote: > > From: Frank Chang <[email protected]> > > > > vsll.vi, vsrl.vi, 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? Frank Chang
