[PATCH] D109300: [AMDGPU] Make vector superclasses allocatable

[Christudasan Devadasan via Phabricator via llvm-commits]

cdevadas added a comment.

In D109300#3021674 <https://reviews.llvm.org/D109300#3021674>, @arsenm wrote:

> In D109300#3019936 <https://reviews.llvm.org/D109300#3019936>, @cdevadas wrote:
>
>> In D109300#3018937 <https://reviews.llvm.org/D109300#3018937>, @rampitec wrote:
>>
>>> Thanks. FoldImmediate() and Global ISel seems to be last issue to me.
>>
>> The MAIInst uses AVSrc_32 for src0 & src1 operands.
>> https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/AMDGPU/VOP3PInstructions.td#L378
>>
>> I am not sure we can do something to prevent GIsel from choosing AV classes here.
>> Yes, the w/a in FoldImmediate was done to adjust the register class as per the opcode we choose.
>
> Something is missing code to constrain or insert a constraining copy when the instructions are initially emitted

During InstructionSelect, the MIOperands' regclasses are assigned for the first time with llvm::constrainOperandRegClass. 
https://github.com/llvm/llvm-project/blob/main/llvm/lib/CodeGen/GlobalISel/Utils.cpp#L104 indicates that the regclasses are derived from the instruction definition itself.
Only when the regclass is unallocatable, the selected regbank is used to restrain the regclass for the MO (https://github.com/llvm/llvm-project/blob/main/llvm/lib/CodeGen/GlobalISel/Utils.cpp#L114).
This is the reason SRC0 & SRC1 of MAIInst get AV class even though regbankSelect has managed to give them both VRegBank.
Should we restrain the MIOperand regclasses based on the incoming regbank when the corresponding RC in the instruction definition is its superclass?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109300/new/

https://reviews.llvm.org/D109300