Matt Arsenault via llvm-dev
2019-Feb-27 00:30 UTC
[llvm-dev] Dealing with illegal operand mappings in RegBankSelect
> On Feb 26, 2019, at 7:25 PM, Quentin Colombet <qcolombet at apple.com> wrote: > > > >> On Feb 26, 2019, at 4:18 PM, Matt Arsenault <arsenm2 at gmail.com <mailto:arsenm2 at gmail.com>> wrote: >> >> >> >>> On Feb 26, 2019, at 7:01 PM, Quentin Colombet <qcolombet at apple.com <mailto:qcolombet at apple.com>> wrote: >>> >>> 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 applyMappingImpl (first sample case is https://reviews.llvm.org/D58512 <https://reviews.llvm.org/D58512>) > > Wow, that’s quite a lot of code to fix a couple of operands :) > > Couldn’t we do that expansion as part of the selection of the “pseudo copy”?That would require looking for all the uses of the copy and applying this to them. It’s really the use needs to be rewritten, and not a property of the copy. The only use I would have for the copy is as as a means of passing which registers were already created for the new mapping, after which point I would need to delete it. -Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190226/43f90561/attachment.html>
Quentin Colombet via llvm-dev
2019-Feb-27 00:46 UTC
[llvm-dev] Dealing with illegal operand mappings in RegBankSelect
> On Feb 26, 2019, at 4:30 PM, Matt Arsenault <arsenm2 at gmail.com> wrote: > > > >> On Feb 26, 2019, at 7:25 PM, Quentin Colombet <qcolombet at apple.com <mailto:qcolombet at apple.com>> wrote: >> >> >> >>> On Feb 26, 2019, at 4:18 PM, Matt Arsenault <arsenm2 at gmail.com <mailto:arsenm2 at gmail.com>> wrote: >>> >>> >>> >>>> On Feb 26, 2019, at 7:01 PM, Quentin Colombet <qcolombet at apple.com <mailto:qcolombet at apple.com>> wrote: >>>> >>>> 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 applyMappingImpl (first sample case is https://reviews.llvm.org/D58512 <https://reviews.llvm.org/D58512>) >> >> Wow, that’s quite a lot of code to fix a couple of operands :) >> >> Couldn’t we do that expansion as part of the selection of the “pseudo copy”? > > That would require looking for all the uses of the copy and applying this to them. It’s really the use needs to be rewritten, and not a property of the copy.Ok so what you’re saying is: 1 sgpr = copy vgpr 2 = use sgpr We wouldn’t change the expansion of the copy in 1, but the use in 2. That’s interesting because from RBS point of view, the use in 2 is supposed to be final (in the sense not needed any rewriting). I am starting to think that the way you handle it is probably the right way since it is so off of what RBS’ expectations are. Let me sleep on this to see if I can come up with something else.> The only use I would have for the copy is as as a means of passing which registers were already created for the new mapping, after which point I would need to delete it.Could you describe in pseudo code what the expansion of vgpr into sgpr looks like? e.g., = use vgpr And you only support = use sgpr> > -Matt-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190226/fbb8f015/attachment.html>
Matt Arsenault via llvm-dev
2019-Feb-27 00:58 UTC
[llvm-dev] Dealing with illegal operand mappings in RegBankSelect
> On Feb 26, 2019, at 7:46 PM, Quentin Colombet <qcolombet at apple.com> wrote: > >> The only use I would have for the copy is as as a means of passing which registers were already created for the new mapping, after which point I would need to delete it. > > Could you describe in pseudo code what the expansion of vgpr into sgpr looks like? > e.g., = use vgpr > And you only support = use sgpr >It’s serializing the vector operation. There’s an additional optimization to reduce the number of loop iterations when multiple work items/lanes/threads have the same value in them which happens in practice, but essentially it does: Save Execution Mask For (Lane : Wavefront/Warp) { Enable Lane, Disable all other lanes SGPR = read SGPR value for current lane from VGPR VGPRResult[Lane] = use_op SGPR } Restore Execution Mask Eventually it might be nice to have optimizations to only emit one of these loops when multiple consecutive instructions need the same register handled (which I suspect will happen frequently with image samplers), but I haven’t really thought about what that should look like yet. -Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190226/589014a5/attachment.html>