[llvm-dev] [RFC] Array Register Files

[Nicolai Hähnle via llvm-dev]

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?

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.

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.