[PATCH] D131959: [AMDGPU] Fix SDST operand of V_DIV_SCALE to always be VCC

Pierre van Houtryve via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Aug 23 01:43:11 PDT 2022


Pierre-vh added a comment.

In D131959#3740590 <https://reviews.llvm.org/D131959#3740590>, @rampitec wrote:

> In D131959#3740396 <https://reviews.llvm.org/D131959#3740396>, @Pierre-vh wrote:
>
>> In D131959#3740314 <https://reviews.llvm.org/D131959#3740314>, @rampitec wrote:
>>
>>> If we prohibit and SDTS except VCC it should be also prohibited in asm/disasm.
>>>
>>> This is not a first instruction which can only have VCC as carry, see any VOP2be instructions, for example V_ADD_CO_U32.
>>>
>>> It shall not have SDST at all and instead impdef VCC. Asm string operand is replaced in the real instruction depending on a wave size, see for example:
>>>
>>>   def _dpp_w32_gfx10 :
>>>     Base_VOP2_DPP16<op, !cast<VOP2_DPP_Pseudo>(opName#"_dpp"), asmName> {
>>>       string AsmDPP = !cast<VOP2_Pseudo>(opName#"_e32").Pfl.AsmDPP16;
>>>       let AsmString = asmName # !subst("vcc", "vcc_lo", AsmDPP);
>>>       let isAsmParserOnly = 1;
>>>       let WaveSizePredicate = isWave32;
>>>     }
>>>
>>> Plus you will need to enforce SDST encoding field to VCC for these instructions only, no need in a new SDstIsAlwaysVCC.
>>
>> Will I need to create 2 variants of the instruction, a wave32/wave64 variant (e32/e64 if I understand correctly) for this to work?
>
> You need a single pseudo, but 2 different real instructions with different WaveSizePredicate. V_ADD_CO_U32 is not a good example after all, it does that for sdwa/dpp, which it does not have. You can pick a similar example from VOPCInstructions.td looking for _w32/_w64 variants.
> Note, this instruction only has _e64 variant.
>
>> Also for the asm/disasm, do I need to change the asmparser/add tests to verify everything other than VCC is rejected in the dst?
>>
>>> enforce SDST encoding field to VCC for these instructions only
>>
>> How can I do this? Do I also follow the example of V_ADD_CO_U32?
>
> Just enforce sdst field to !cast<int>(VCC.HWEncoding) (i.e. 0x6a) in the Real class.

I've written the following for one of the  real instructions, and I get a encoding conflict (VCC/VCC_LO have the same encoding).
Am I doing this wrong?

Also, do I need to create a new "Real" class specifically for this, or should I just add a flag to the VOP_PROFILE & change the existing classes to create _w32/64 variants?
Thanks

  multiclass VOP3be_VCCSDST_Real_vi<bits<10> op> {
    let sdst = !cast<int>(VCC_LO.HWEncoding), WaveSizePredicate = isWave32 in
    def _vi_w32 : VOP3_Real<!cast<VOP_Pseudo>(NAME#"_e64"), SIEncodingFamily.VI>,
                  VOP3be_vi <op, !cast<VOP_Pseudo>(NAME#"_e64").Pfl>;
  
    let sdst = !cast<int>(VCC.HWEncoding), WaveSizePredicate = isWave64 in
    def _vi_w64 : VOP3_Real<!cast<VOP_Pseudo>(NAME#"_e64"), SIEncodingFamily.VI>,
                  VOP3be_vi <op, !cast<VOP_Pseudo>(NAME#"_e64").Pfl>;
  }



  [build] Decoding Conflict:
  [build] 		................................1101000111100000.1101010........
  [build] 		................................1101000111100000................
  [build] 		................................110100..........................
  [build] 		................................................................
  [build] 	V_DIV_SCALE_F32_vi_w32 ________________________________1101000111100000_1101010________
  [build] 	V_DIV_SCALE_F32_vi_w64 ________________________________1101000111100000_1101010________
  [build] Decoding Conflict:
  [build] 		................................1101000111100001.1101010........
  [build] 		................................1101000111100001................
  [build] 		................................110100..........................
  [build] 		................................................................
  [build] 	V_DIV_SCALE_F64_vi_w32 ________________________________1101000111100001_1101010________
  [build] 	V_DIV_SCALE_F64_vi_w64 ________________________________1101000111100001_1101010________


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131959



More information about the llvm-commits mailing list