[Libre-soc-isa] [Bug 553] svp64 register mapping to accomidate AltiVec vectors expanding fp registers

[bugzilla-daemon at libre-soc.org]

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

Jacob Lifshay <programmerjake at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://bugs.libre-soc.org/
                   |                            |show_bug.cgi?id=558

--- Comment #1 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from bug #558 comment #57)
> (In reply to Jacob Lifshay from bug #558 comment #56)
> 
> > 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?
> 
> i'd really like to use both (dynamically), that was what the CR8x8 matrix
> concept was.  there is room to overload elwidth to do it... however the
> implications for the DMs are so complex that it would be foolish to try as a
> first iteration.
> 
> given that if we *don't* use vertical numbering on CRs we are forced instead
> to add a 1 year delay on the critical path it is clearly unacceptable to use
> the SVP scheme... for CRs

I would argue that we should use vertical numbering for all int/fp/cr register
files since that makes for nice consistency as well as having benefits for
register allocation.

you could think of it as extending OpenPower v3.1 scalar to have 4-reg vectors
at every int/fp reg and 8-element vectors at every CR field.

This means we don't have to extend gcc's register allocator to handle ranges
for the MVP, *saving several months time*. this will limit gcc for now to
handling 8-element vectors or 256-bit vectors, whichever is smaller.

> given that it is clearly unacceptable to completely cut off entire swathes
> of the regfile from scalar operations

that's not a valid reason to prefer horizontal since both horizontal and
vertical schemes cut off an equal number of registers.

> forcing the use of convoluted
> predicated mv operations if we *do* use vertical numbering on FP and Int
> operations it is clearly unacceptable to use the vertical numbering
> scheme... for FP and INT.

We don't realistically need that many scalar registers, 64 is (more than?)
sufficient. the 128 are needed for vector purposes.

> conclusion: vertical numbering for CRs (reluctantly), horizontal numbering
> for INT and FP.

I disagree for the above reasons.

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