search for: regbankselect

Hi all, this is the second email for the round table follow-up, this time regarding the issues around the greedy RegBankSelect and alternative mappings. The issue I brought up was that because RegBankSelect goes top-down, it never looks at all available mappings for the operands when considering which of the mappings to apply to the current instruction. In our architecture we have one register bank dedicated to pointe...

Hi Quentin, thanks for picking up the conversation! > I think we should step back and check what we want before investing any time in some rewrite. That is a very fair point and I might have been getting ahead of myself in my last email. What I would like to see from RegBankSelect is to produce the mapping with the overall lowest cost. Keeping track of all different combinations of mappings will certainly be non-trivial however, so I wonder if there is a smart way to do this without spending too much compilation time. Ideally for instructions with no operands (like G_CO...

Hi, I’m looking at RegBankSelect’s partially implemented support for deciding to split a value between multiple registers and I’m wondering if it’s actually intended to solve the problem I’m trying to use it for. RegisterBankInfo.h has this example mapping table: /// E.g., /// Let say we have a 32-bit add and a <2 x 32-bit&...

...e conversation! >> >> > I think we should step back and check what we want before investing >> any time in some rewrite. >> >> That is a very fair point and I might have been getting ahead of >> myself in my last email. >> What I would like to see from RegBankSelect is to produce the mapping >> with the overall lowest cost. Keeping track of all different >> combinations of mappings will certainly be non-trivial however, so I >> wonder if there is a smart way to do this without spending too much >> compilation time. >> >>...

...; >>> I don’t get what you mean by “applyMapping to deal with it”. Won’t applyMapping will insert copies to rewrite these, hence how is this different from what the repairing code does? >>> Unless, maybe, you’re talking about the target specific RegisterBankInfo::applyMapping not RegBankSelect::applyMapping. >>> >>> If that’s the case what do you do in here that we could maybe generalize? >>> >> Sorry, I mean report them as legal so they are left as-is with no copy inserted. I can see the operand is illegal and do everything needed in the target applyMa...

...ome operations on AMDGPU require operands which must be in a register bank that is impossible to copy from another. The operation needs to be rewritten in a complex way to avoid the illegal copy. >> >> Currently if I correctly report the required register banks in the operand mapping, RegBankSelect happily inserts the illegal copies, somehow concluding they are cheap (I would at least hope there’s an assert or something). > > I would have hoped that we end up with a huge cost. > The assumption is that you can copy to/from any pair of register bank, then the idea is that the copy sho...

Hi, Some operations on AMDGPU require operands which must be in a register bank that is impossible to copy from another. The operation needs to be rewritten in a complex way to avoid the illegal copy. Currently if I correctly report the required register banks in the operand mapping, RegBankSelect happily inserts the illegal copies, somehow concluding they are cheap (I would at least hope there’s an assert or something). So far I’ve worked around this by lying and reporting all of the invalid source register banks as legal. applyMapping then checks these registers and creates the new vregs a...

...t I would like to have your feedbacks. >> >> >> ** Context ** >> >> In GlobalISel, the selection process will be split into separate passes. >> As a reminder, this is the suggested pipeline: >> LLVM IR -> IRTranslator -> (G)MI -> Legalizer -> RegBankSelect -> Select -> MI >> >> Each pass produces MachineInstr with some properties and has some conditions on which it operates. >> For instance, after the Legalizer everything is legal and before RegBankSelect everything must be legal. >> >> Targets can inject passes...

.../lists.llvm.org/pipermail/llvm-dev/2013-August/064734.html http://lists.llvm.org/pipermail/llvm-dev/2013-August/064760.html To summarize with my own words and feelings that gives: To me the pointer/integer distinction is a way for you to specify the register classes you want. This is something the RegBankSelect pass will do for you and this distinction should not be necessary to produce efficient or correct code. If that doesn’t work, you should be able to have target specific pass to select what you want directly after the translation or with a custom translation. One can envision some kind of IRTransla...

...-oGUzwX/eglibc-2.19/stdlib/abort.c:91:0 #5 0x00007f9192764bf6 __assert_fail_base /build/eglibc-oGUzwX/eglibc-2.19/assert/assert.c:92:0 #6 0x00007f9192764ca2 (/lib/x86_64-linux-gnu/libc.so.6+0x2fca2) #7 0x0000000003d70eb9 (/work/llvm/build/bin/clang-6.0+0x3d70eb9) #8 0x0000000003d6b00c llvm::RegBankSelect::applyMapping(llvm::MachineInstr&, llvm::RegisterBankInfo::InstructionMapping const&, llvm::SmallVectorImpl<llvm::RegBankSelect::RepairingPlacement>&) (/work/llvm/build/bin/clang-6.0+0x3d6b00c) #9 0x0000000003d6b366 llvm::RegBankSelect::assignInstr(llvm::MachineInstr&) (/wor...

...1:0 >> #5 0x00007f9192764bf6 __assert_fail_base /build/eglibc-oGUzwX/eglibc-2.19/assert/assert.c:92:0 >> #6 0x00007f9192764ca2 (/lib/x86_64-linux-gnu/libc.so.6+0x2fca2) >> #7 0x0000000003d70eb9 (/work/llvm/build/bin/clang-6.0+0x3d70eb9) >> #8 0x0000000003d6b00c llvm::RegBankSelect::applyMapping(llvm::MachineInstr&, llvm::RegisterBankInfo::InstructionMapping const&, llvm::SmallVectorImpl<llvm::RegBankSelect::RepairingPlacement>&) (/work/llvm/build/bin/clang-6.0+0x3d6b00c) >> #9 0x0000000003d6b366 llvm::RegBankSelect::assignInstr(llvm::MachineInstr&am...

...pensate, later passes use the FP operations on those values to guess what kind of value is being stored within that virtual register. This means that i32/float loads get translated into the same thing, and only when that value is used, say by an fadd, then will we know that it was an FP value. The regbankselect pass on AArch64 currently tries to walk uses/defs in order to guess what kind fo regbank to assign to vregs. This however doesn’t work all the time, and most commonly, it doesn’t work when a load of an FP value is used in a loop. In that case, the FP users are obscured by PHIs which make it difficu...

...n on this, I'll send an email when it's done. If that goes well I don't have anything against making the switch. For the record, here's a summary of issues that were deferred for later on (some of which are optimization-ish and we might decide to never do at -O0 at all): * Crash in RegBankSelect for half fp types: https://bugs.llvm.org/show_bug.cgi?id=32560 * Improving constant placement: http://bugs.llvm.org/show_bug.cgi?id=32561 * Fancy switch lowering * Transforming division-by-constant-power-of-2 into right shift AFAICT all the other issues that were brought up were fixed (yay!). Che...

...stdlib/abort.c:91:0 > #5 0x00007f9192764bf6 __assert_fail_base /build/eglibc-oGUzwX/eglibc-2.19/assert/assert.c:92:0 > #6 0x00007f9192764ca2 (/lib/x86_64-linux-gnu/libc.so.6+0x2fca2) > #7 0x0000000003d70eb9 (/work/llvm/build/bin/clang-6.0+0x3d70eb9) > #8 0x0000000003d6b00c llvm::RegBankSelect::applyMapping(llvm::MachineInstr&, llvm::RegisterBankInfo::InstructionMapping const&, llvm::SmallVectorImpl<llvm::RegBankSelect::RepairingPlacement>&) (/work/llvm/build/bin/clang-6.0+0x3d6b00c) > #9 0x0000000003d6b366 llvm::RegBankSelect::assignInstr(llvm::MachineInstr&)...

...getInstrAlternativeMappings() and RegisterBankInfo::getInstrMapping() as separate functions. Could we instead replace these two functions with just one: RegisterBankInfo::getInstrMappings() and then just treat the first mapping in the list as the 'default' mapping to use for 'Fast' RegBankSelect mode? The reason this would make sense (at least for the AMDGPU target) is because both functions need to do the exact same analysis in order to compute the cost and order for the InstrMappings, so we end up with a lot of duplicated computations. -Tom

...stdlib/abort.c:91:0 > #5 0x00007f9192764bf6 __assert_fail_base /build/eglibc-oGUzwX/eglibc-2.19/assert/assert.c:92:0 > #6 0x00007f9192764ca2 (/lib/x86_64-linux-gnu/libc.so.6+0x2fca2) > #7 0x0000000003d70eb9 (/work/llvm/build/bin/clang-6.0+0x3d70eb9) > #8 0x0000000003d6b00c llvm::RegBankSelect::applyMapping(llvm::MachineInstr&, llvm::RegisterBankInfo::InstructionMapping const&, llvm::SmallVectorImpl<llvm::RegBankSelect::RepairingPlacement>&) (/work/llvm/build/bin/clang-6.0+0x3d6b00c) > #9 0x0000000003d6b366 llvm::RegBankSelect::assignInstr(llvm::MachineInstr&)...

...ote: > > On 18 Nov 2015, at 23:52, Quentin Colombet <qcolombet at apple.com> wrote: >> >> To summarize with my own words and feelings that gives: >> To me the pointer/integer distinction is a way for you to specify the register classes you want. This is something the RegBankSelect pass will do for you and this distinction should not be necessary to produce efficient or correct code. >> >> If that doesn’t work, you should be able to have target specific pass to select what you want directly after the translation or with a custom translation. One can envision some...

...when > it's done. If that goes well I don't have anything against making the > switch. > > For the record, here's a summary of issues that were deferred for > later on (some of which are optimization-ish and we might decide to > never do at -O0 at all): > * Crash in RegBankSelect for half fp types: > https://bugs.llvm.org/show_bug.cgi?id=32560 > > > I’ll have a look. > > * Improving constant placement: http://bugs.llvm.org/show_bug.cgi?id=32561 > > > I’ve commented in the PR to mention the localizer technic I was playing > with, if someone want...

...gt;> switch. >>> >> >>> >> For the record, here's a summary of issues that were deferred for >>> >> later on (some of which are optimization-ish and we might decide to >>> >> never do at -O0 at all): >>> >> * Crash in RegBankSelect for half fp types: >>> >> https://bugs.llvm.org/show_bug.cgi?id=32560 >>> >> >>> >> >>> >> I’ll have a look. >>> >> >>> >> * Improving constant placement: >>> >> http://bugs.llvm.org/show_bug.cg...

...t instructions of the same size are not simultaneously available. This problem was already addressed here http://lists.llvm.org/pipermail/llvm-dev/2017-July/114978.html for G_LOAD/G_STORE. Legality of an instruction should not depend on surrounding instructions. Because of that, approach from regbankselect that iterates through uses of G_LOAD def register and checks if some of the uses was an generic floating point instruction should not be an option for legalizer. Since GlobalISel Legalizer cannot distinguish between them using only LLT, only other option that I can see at this moment is having...