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

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=558

--- 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.