Konstantin Vladimirov via llvm-dev
2016-May-10 20:29 UTC
[llvm-dev] [llvm dev] do we have allocator hook to use maximum different registers?
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? In GCC this option is known as -frename-registers. --- With best regards, Konstantin
Quentin Colombet via llvm-dev
2016-May-10 20:41 UTC
[llvm-dev] [llvm dev] do we have allocator hook to use maximum different registers?
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
Gerolf Hoflehner via llvm-dev
2016-May-11 00:32 UTC
[llvm-dev] [llvm dev] do we have allocator hook to use maximum different registers?
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
Adam Husar via llvm-dev
2016-May-16 09:56 UTC
[llvm-dev] [llvm dev] do we have allocator hook to use maximum different registers?
Hello Konstantin, we approach this issue by using pre-RA scheduling and it works fine, although for very large basic blocks, the effect is not so good, because it leads to more spilling comparted to the case when a pre-RA schedule is not used. I also remember that there is some interface for schedulers to do the register renaming, but as far as I know, we haven't used it yet. Best regards Adam On Tue, 10 May 2016 22:41:01 +0200, 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 >-- Adam Husar Compiler Group Leader T +420 541 141 443 S adamhusar Codasip.com
Maybe Matching Threads
- what is official way to determine if we are running lto 2nd stage?
- what is official way to determine if we are running lto 2nd stage?
- what is official way to determine if we are running lto 2nd stage?
- what is official way to determine if we are running lto 2nd stage?
- Intrinsic opt failure