https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120362
Li Pan <pan2.li at intel dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #15 from Li Pan <pan2.li at intel dot com> ---
(In reply to Andrew Waterman from comment #14)
> > Let us summon the RISC-V judge!!!
>
> The key is that vtype.vill affects only those instructions that depend on
> vtype. vl<nf>r and vs<nf>r do not depend on vtype and so are unaffected by
> vtype.vill.
>
> > vmv1r also doesn't depend on a specific vtype
>
> This actually isn't the case: unlike vl<nf>r and vs<nf>r, the vmv<nf>r
> instructions' vstart settings are SEW-specific, and so they have a vtype
> dependence. This is arguably a flaw in the ISA, but the fact is that the
> moves are more restricted than the loads and stores.
>
> > I mean I wouldn't mind not fixing this if it's indeed a hardware issue but
> > e.g. the Banana Pi is widespread and it might look unfortunate if we just
> > SIGILL for a preventable reason.
>
> It does seem like a hardware bug, but I'm sympathetic to this point of view,
> assuming we aren't giving anything up by working around it.
I see, thanks Waterman.
It's mostly one hardware bug from my perspective, given that the vmv<nf>r
depends on a vtype while vl<nf>r and vs<nf>r do not. Close this PR.
