[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

Luke Kenneth Casson Leighton <lkcl at lkcl.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
                 CC|                            |lkcl at lkcl.net
             Status|CONFIRMED                   |RESOLVED

--- Comment #2 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #1)

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

jacob: i already made it clear that the complexity in understanding the
fractional numbering is too high.  it was almost two weeks before i understood
it.

the only reasob for considering it for CRs is because we're forced to.  and CRs
are Hell anyway, with the low 2 bits not being incremented through.


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

i know.  i'm not happy about it.  but:
a) tough.  the hardware is too complex.  i have said it five or six times now:
i am not redesigning the routing on the regfile.

b) there exists some explicit control over gcc fp/int regs where there is NONE
on CRs.  as a concept they do not exist AT ALL in the frontend.  we are
therefore FORCED to reluctantly use an alternative scheme.

> this will limit gcc for now to
> handling 8-element vectors or 256-bit vectors, whichever is smaller.

you are completely forgetting about the hardware design.  i do not want at this
incredibly late stage to THINK about any kind of FP/INT redesign involving
renumbering.

the only reason i'm considering it at all is because CRs are only 4 bits. 
those can be batched up in groups of 8 which is only 32 wires.

the DMs are going to be shit, basically.  supporting mfcr is going to be a huge
penalty on performance and require a rewrite of the whole CR pipeline.



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

it's not about the quantity.

the way in which they are cut off forces the use of additional expensive
instructions.


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

having a system where interaction between the two PUNISHES developers for doing
so is not going to fly.

i'm not running that by the OPF ISA WG.

i am really sorry, this one is also invalid.

we are under time pressure and we are wasting time discussing this.

we are not going to be adding 128 bit or VSX any time in the next 2+ years.

the INT/FP regfile design and routing is extremely complex, was done months
ago, is *specifically* targetted at 64 bit and cannot change.

none of us can earn any donations from NLnet for continuing to discuss this.

can we please stop discussing this, i am getting very fed up of repeating
myself, and getting very concerned that i am not earning any money for having
to repeatedly go over something that is not going to happen.

can we PLEASE move on to implementation.

you keep putting me under huge pressure repeatedly by asking again and again
for something that i have already said no on multiple times.  i appreciate that
you want to do a full investigation but this is getting too much.  we HAVE to
stop, i cannot cope.

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