[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 #55 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(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.

or, the REMAP system has to be deployed, which is even more expensive than mv.x
or predication.

OpenPOWER v3.0B scalar instructions cannot get at them *at all*.

for CRs this is... well, it's not really ok but the alternative is worse.  if
it was ok to do that "turnaround" (support horizontal *and* vertical numbering
i.e. support *both* schemes) it would solve this but the DMs become far too
complex.

for INT and FP it is definitely not ok.

it took me a while to remember that this was why we came up with the odd system
in the first place.

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