[llvm] r318675 - [AMDGPU][MC][GFX8][GFX9] Corrected names of integer v_{add/addc/sub/subrev/subb/subbrev}

Matt Arsenault via llvm-commits llvm-commits at lists.llvm.org
Mon Nov 27 14:12:10 PST 2017


> On Nov 20, 2017, at 13:24, Dmitry Preobrazhensky via llvm-commits <llvm-commits at lists.llvm.org> wrote:
> 
> int AMDGPUInstrInfo::pseudoToMCOpcode(int Opcode) const {
>   SIEncodingFamily Gen = subtargetEncodingFamily(ST);
> +
> +  if ((get(Opcode).TSFlags & SIInstrFlags::renamedInGFX9) != 0 &&
> +    ST.getGeneration() >= AMDGPUSubtarget::GFX9)
> +    Gen = SIEncodingFamily::GFX9;
> +
>   if (get(Opcode).TSFlags & SIInstrFlags::SDWA)
>     Gen = ST.getGeneration() == AMDGPUSubtarget::GFX9 ? SIEncodingFamily::SDWA9
>                                                       : SIEncodingFamily::SDWA;
> 
> -  if ((get(Opcode).TSFlags & SIInstrFlags::F16_ZFILL) != 0 &&
> -      ST.getGeneration() >= AMDGPUSubtarget::GFX9)
> -    Gen = SIEncodingFamily::GFX9;
> -
>   int MCOp = AMDGPU::getMCOpcode(Opcode, Gen);
> 

I’m having trouble with this part of the change with my patch to start selecting the carry-less versions. When this is used on V_ADD_U32 for example, it fails to find an entry in the table and assertions fail.

The generated table entries for it look like

 { AMDGPU::V_ADD_U32_e32, (uint16_t)-1U, (uint16_t)-1U, (uint16_t)-1U, (uint16_t)-1U, AMDGPU::V_ADD_U32_e32_gfx9 },
 { AMDGPU::V_ADD_U32_e64, (uint16_t)-1U, (uint16_t)-1U, (uint16_t)-1U, (uint16_t)-1U, AMDGPU::V_ADD_U32_e64_gfx9 },

It seems the last column is only used for instructions with the renamedInGFX9 bit set. These don’t have it set, since they are sort of new instructions. What is the intent of the _gfx9 naming scheme, and this bit? I think we have an inconsistency here in how these instruction changes are handled. Is the intent of the bit that it really needs to look in the gfx9 section of the table?

Currently we have a mix of the real encoded instructions named _vi and _gfx9. Some of the new gfx9 only instructions are still named _vi to indicate they use the _vi encoding. Is the intent to move all machine encoded instructions to subtarget specific versions?

-Matt


More information about the llvm-commits mailing list