[llvm-dev] [llvm dev] do we have allocator hook to use maximum different registers?

[C Bergström via llvm-dev]

IOP is pretty common with mobile.. (maybe that's changed?)

Apple A9, Qualcomm Kryo == OoO
latest kirin == mixed a53/a72 arm cores

For me IOP optimizations around regalloc are very interesting.. please
feel free to share any verbose details. It's something we may
potentially be able to help with as well as upstream.


On Wed, May 11, 2016 at 8:32 AM, Gerolf Hoflehner via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> On an OOO register renaming should make this issue mute. On an IOP experimenting with round robin vs stack assignment could be interesting. For caller save registers round robin would be ok. For callee saved registers the potential extra prolog/epilog spills/fills need to be taken into account. And this is probably just the start of the tuning fun.
>
> -Gerolf
>
>> On May 10, 2016, at 1:41 PM, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>>
>> Hi Konstantin,
>>
>>
>>> On May 10, 2016, at 1:29 PM, Konstantin Vladimirov via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>>>
>>> Hi,
>>>
>>> Default register allocator tries to reuse the same registers over and
>>> over again even if register file have a plenty of registers to use.
>>> This creates parasite false dependencies and makes scheduling less
>>> effective.
>>>
>>> How to instruct allocator (may be override some virtual function in
>>> mine backend?) that it is profitable to use maximum number of
>>> available registers with minimal dependencies?
>>
>> That is not possible and in the current scheme that would be hard to add. Indeed, the greedy reg alloc assigns live-ranges in an order based on some priority cost model. Thus, we do not know how close, in the scheduling order, two live-ranges are when we assign them in a row.
>>
>> Cheers,
>> -Quentin
>>
>>> In GCC this option is
>>> known as -frename-registers.
>>
>>>
>>> ---
>>> With best regards, Konstantin
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev