[PATCH] D132483: [AMDGPU][GlobalISel] Improve BFI Pattern Matching
Pierre van Houtryve via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Wed Aug 24 01:41:16 PDT 2022
Pierre-vh added a comment.
The copy hoisting works for BFI, but it's not an ideal solution I think because for other cases (like the insertelement tests) it can worsen codegen. I tried to make it as local as possible but I couldn't get rid of all the cases where it's unprofitable to move the copy "out".
If copy hoisting is an acceptable solution and we want to move forward with it maybe it needs to be made smarter, e.g. look at the whole expression tree, try to compute how many copies could be inserted and where and choose the solution that inserts the least copies? Perhaps it could even move copies downwards, e.g. currently it can transform a tree of expressions from SGPR to VGPR, but maybe it could do the opposite as well if it introduces less copies?
Thoughts? Should I keep going with this approach and try to make it smarter and better, or give it up?
Ideally I'd really like to be able to just fix the tablegen but I haven't found a way to do it properly.
There's also another annoying case in one of the BFI tests where the RegBankSelect adds 2 identical copies.
It prevents BFI from being selected because %6/%7 aren't identical (despite referencing the same physical register).
This could be fixed by another combine (?) or we could maybe change GISe's `GIM_CheckIsSameOperand` l so it looks through copies of physregs to vregs?
%6:vgpr(s32) = COPY %2:sgpr(s32)
%3:vgpr(s32) = G_XOR %1:vgpr, %6:vgpr
%4:vgpr(s32) = G_AND %0:vgpr, %3:vgpr
%7:vgpr(s32) = COPY %2:sgpr(s32)
%5:vgpr(s32) = G_XOR %7:vgpr, %4:vgpr
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D132483/new/
https://reviews.llvm.org/D132483
More information about the llvm-commits
mailing list