- Besides checking whether the RC has legal type for the corresponding operand, need to check that type's legality from the whole target's point of view. That's because a specific type may be designated as a legal one per RC for certain instructions but it may not be generally legal in a target. In that case, we still need to legalize that value through bitcast so that the input and output of that inline asm is well prepared for its itself or its user.
I'm not sure I see what case this fixes exactly. The concept of type legality is so convoluted already.
This is a separate change. All of the test changes are GLobalISel, and only from this part
this change fixes the issue shown in llvm/test/CodeGen/AMDGPU/inline-asm.i128.ll. I was working on a similar issue reported but found your previous change removing i128 as a legal type.
llvm/test/CodeGen/AMDGPU/inline-asm.i128.ll is the exact test case for this issue and this fix. All test cases in this change just revert to the previous one. But, that newly added test is left intentionally as the regression of this fix.
So the point is to re-add i128 as a legal type?
I think I see where this is going, but it's hack on a hack. We want the type to occupy the registers, but we can't make them legal since we can't opt out of the consequences of doing so. This at least needs a comment explaining this
But, there we really should check TLI.isTypeLegal() in addition to checking RC legality. The latter is specific to that inlined assembly and the former is target-wise. Both should be checked.