[llvm-dev] [RFC] Array Register Files

[Robin Kruppe via llvm-dev]

On Tue, 9 Oct 2018 at 04:03, Luke Kenneth Casson Leighton via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> nicolai, hi,
>
> couple things occurred to me, after writing this out
> https://libre-riscv.org/llvm_vector_backend/
>
> (1) a way to express the link between "what's wanted" and "what's
> available" is needed.  i.e. there needs to be a key-value store.  as
> they stand, proposed ARF and Reg classes only express "what's
> available", they don't express "what's wanted".
>
> (2) really SV and RVV both absolutely critically require that "length"
> CSR (VL) to be part of the data structures, in order for the registers
> to actually be "arrays", at all.  if there is no length specified (at
> the "what's wanted" level), there's no way for the backend to
> determine "what's available".
>
> (3) if the length of an array is specified as part of the data
> structures, microarchitectures that don't have that concept can simply
> set that to "1" in all data structures.  i *think* that means that for
> AMDGPU standard vector regs, length would be 1, and for those special
> shader registers, it would be 12.  or 1-12.  or whatever they had been
> globally set to for the duration of the application lifetime.
>
> (4) VL ties in with robin kruppe's intermediary representation RFC
> (initially designed for RVV). i think it's important to get in touch
> with him on that.

Luke, I've been hesitant to reply to you here because I wanted to
write a more helpful explanation than I managed below, but since you
name dropped me and this subthread is getting larger and larger, I'll
just go ahead and say: I don't know what you are talking about
whenever you mention RVV in this context. My opinion after having
constructed most of a prototype backend for RVV is that the existing
ways of representing registers in LLVM work just fine for it and the
pain points that do exist are completely different from the ones this
RFC revolves around.

Please read Fabian's great explanation carefully. In particular note
how AMDGPU instructions use groups of multiple architectural registers
that are numbered consecutively, which is unrelated to how a single
vector register contains multiple scalar values. The former concept
does not exist in RVV (instructions reference 1-3 independent source
registers and write to one destination register), nor do things like
an indirectly addressable register field that one could use for an
alloca'd array. So even an extended RVV encoding with the same number
of architectural vector registers as AMDGPU would not run into most of
the problems that motivate this RFC. Maybe the compile time issues
from the sheer number of registers, as 256 registers is quite a bit
more than the few dozens of registers of most CPU architectures.
However, since RVV registers are isolated from each other instead of
being the leaves in a massive hierarchy of artificial "combined"
registers, even that problem seems different (and likely less severe)
from what AMDGPU faces.


Cheers,
Robin

> (5) the idea of unioning traditional register classes is a good one: i
> would hesitate to special-case that.  if the ARF and Reg classes are
> not capable of expressing the traditional register classes, i would
> say that there's something wrong with how the ARF and Reg classes are
> designed.
>
> l.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev