[Libre-soc-bugs] [Bug 558] gcc SV intrinsics concept

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Wed Jan 13 19:44:39 GMT 2021


--- Comment #56 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #55)
> (In reply to Jacob Lifshay from comment #53)
> > Another difference is the special case for svp64 int/fp/cr extra2/extra3
> > decoding is removed -- 
> that's what i ended up doing, and as i explained, unfortunately the
> combination of removing the different scheme for acalar and turning the
> sequential iteration sideways (vertical) prohibits scalar SV entirely from
> accessing sone of the Vector registers.
> with the linear straight sequential numbering and the original sv-extension
> scheme at least a Vector operation can take place using a lower-numbered
> dest register (starting between r0 and r60 or so) then any Scalar-SV or just
> plain v3.0B scalar operations can get access to the *full* range of results.
> with the scheme that you proposed *this is not possible* because the
> numbering is hardcoded to zeros in the lower bits.  SV scalar is forced to
> engage a predicated VSELECT mv or a mv.x to copy every other vector element
> result into alternative locations that the scalar numbering *can* get at.

So, to be clear, you're advocating for not using the scheme I proposed just
now, or not using the scheme I proposed 18 months ago as part of the SVP for
RISC-V spec?

You are receiving this mail because:
You are on the CC list for the bug.

More information about the libre-soc-bugs mailing list