Details
Diff Detail
Event Timeline
llvm/lib/Target/AMDGPU/GCNDPPCombine.cpp | ||
---|---|---|
420 | Why is this a SetVector? | |
459–462 | I think this won't work in the case where the operand itself has a subregister. %0:vreg_64 = REG_SEQUENCE %vreg_64.sub0, sub1, %vreg_64.1, sub0 I think you can use composeSubRegIndices here | |
471 | No else after continue |
llvm/lib/Target/AMDGPU/GCNDPPCombine.cpp | ||
---|---|---|
420 | I will try to add if several times, for each subreg. Thus set. I guess it can be just SmallSet though. |
llvm/lib/Target/AMDGPU/GCNDPPCombine.cpp | ||
---|---|---|
459–462 | It cannot directly happen because we are in SSA and def must be a result of mov_dpp, i.e. defining the whole register. |
llvm/lib/Target/AMDGPU/GCNDPPCombine.cpp | ||
---|---|---|
530–534 | This seems like a questionable way to preserve undefs. Can you avoid doing this by checking getVRegDef? |
llvm/lib/Target/AMDGPU/GCNDPPCombine.cpp | ||
---|---|---|
530–534 | What's wrong with it? A register either has def or not. The other way would be to keep all reg_sequences along with the info about all subregs, if they were combined or not. |
llvm/lib/Target/AMDGPU/GCNDPPCombine.cpp | ||
---|---|---|
355 | How mov can define subreg in the SSA? |
llvm/lib/Target/AMDGPU/GCNDPPCombine.cpp | ||
---|---|---|
355 | That is not necessarily a mov anymore, it can be a reg_sequence operand now. But I guess this is part of older patch, because all reg_sequences are processed inside this function now. I probably need to remove it. |
llvm/lib/Target/AMDGPU/GCNDPPCombine.cpp | ||
---|---|---|
530–534 | What if the instruction were incorrectly erased? The undef flag would have been present and this would no longer catch it |
How mov can define subreg in the SSA?