[llvm-dev] [RFC] Array Register Files

[Matthias Braun via llvm-dev]

> On Oct 10, 2018, at 1:51 AM, Nicolai Hähnle <nhaehnle at gmail.com> wrote:
> 
> On 09.10.2018 19:44, Matthias Braun wrote:
>> The new encoding would only support sequences of registers. What would we do if we need differently constructed tuples?
> 
> How realistic is that requirement?
Looking around LLVM it seems to be very rare, but there are the *Spc register classes in ARMRegisterInfo.td

> 
> Obviously it's good to be flexible, but there's a real cost in terms of compile time, mental overhead, and possibly also in terms of algorithmic flexibility.
> 
> 
>> So I'd rather we keep expressing things through register classes and have register classes define how tuples are constructed>
>> i.e. if you have a 4 tuple class, then you know that register number 4 in this class is the (r4,r5,r6,r7) tuple. In the class of even numbered register pairs, register number 1 would be (r2, r4), etc.
>> This is more or less how things already work today. The main thing that needs to change IMO is the assumption that we can precompute everything. We need ways to create register classes that can computationally enumerate registers, come up with matching lanemasks, etc. At the same time we need to force ourself to not make any assumption that we know all registers and classes upfront. That would mean we cannot use RegAliasIterator or preallocate a double linked list for every register in MachineRegisterInfo. And the latter two is the problem we need to solve IMO, find ways to force ourself to not rely on completely precomputed register hierarchies and wasting resources by building lists over all possible tuple combinations.
> 
> That does sound like a good start.
I would also expect getting rid of the known register count and known list of register classes assumption to be the biggest challenge/chunk of work of changing the current system.

> 
> Cheers,
> Nicolai
> 
> 
>>> On Oct 9, 2018, at 1:14 AM, Nicolai Hähnle <nhaehnle at gmail.com> wrote:
>>> 
>>> On 08.10.2018 20:20, Matthias Braun wrote:
>>>> In principle we also have the feature of arbitrary register aliases. Though last time I looked it seemed to be only used in one target (I think it was Mips) in a way where you could model things differently and get away with arbitrary aliases if you wanted to change the code. Then again register units also handle aliases already. So to me the implementation/practical side here would be coming up with a concept of dynamic register classes and getting more consistent in using register units wherever possible. I don't see any benefits for the proposed encoding yet...
>>> 
>>> A clear and simple benefit is that it may be possible to implement a bunch of sub/super register stuff without loops, in branch-free code. E.g., MCRegisterInfo::getSubReg would reduce to just a few arithmetic instructions.
>>> 
>>> And sure, I'd be happy to rephrase the whole thing as: making register units the fundamental, first-class object that everything else is built on.
>>> 
>>> Cheers,
>>> Nicolai
>>> 
>>> -- 
>>> Lerne, wie die Welt wirklich ist,
>>> Aber vergiss niemals, wie sie sein sollte.
> 
> 
> -- 
> Lerne, wie die Welt wirklich ist,
> Aber vergiss niemals, wie sie sein sollte.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181011/a40e960a/attachment-0001.html>