[llvm-dev] [RFC] Array Register Files

[Marcello Maggioni via llvm-dev]

+1

I’m late in this thread, but I’m very interested in this development and I would be up for looking to help. In general I feel that whatever change ends up happening we should keep API changes to a minimum and the idea Matthias was proposing about avoid pre-computation seems very promising, because it would basically mean we have the same system with only the generation of the definitions being different.
If anybody interested in this is at the dev meeting next week we could meetup maybe and talk about the goals for this!

Marcello


> On Oct 10, 2018, at 1:51 AM, Nicolai Hähnle via llvm-dev <llvm-dev at lists.llvm.org> 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?
> 
> 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.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181011/7ae2be95/attachment.html>