This is an archive of the discontinued LLVM Phabricator instance.

[AMDGPU][GFX9] Support base+soffset+offset SMEM loads.
ClosedPublic

Authored by kosarev on May 16 2022, 9:07 AM.

Diff Detail

Event Timeline

kosarev created this revision.May 16 2022, 9:07 AM
Herald added a project: Restricted Project. · View Herald TranscriptMay 16 2022, 9:07 AM
kosarev requested review of this revision.May 16 2022, 9:07 AM
Herald added a project: Restricted Project. · View Herald TranscriptMay 16 2022, 9:07 AM
rampitec added inline comments.May 16 2022, 10:19 AM
llvm/test/MC/Disassembler/AMDGPU/gfx9_dasm_all.txt
10083

Is there a decoding conflict which requires to use brackets here? Something from the TODO list?

arsenm added inline comments.May 16 2022, 2:00 PM
llvm/test/MC/AMDGPU/gfx9_asm_smem.s
126

An unaligned offset is suspicious looking but technically not wrong

llvm/test/MC/Disassembler/AMDGPU/gfx9_dasm_all.txt
10083

I'm not sure what this question means. The encoding is always printed in brackets?

I thought we codegened these already? Is this missing a codegen change to use the offsets?

rampitec added inline comments.May 16 2022, 2:03 PM
llvm/test/MC/Disassembler/AMDGPU/gfx9_dasm_all.txt
10083

Printed yes. But disasm tests do not use brackets. These are needed in a stream of bytes when dis cannot find out a boundaries of an instruction itself, and that is usually an indication of disam conflict between subtargets.

kosarev added inline comments.May 16 2022, 11:57 PM
llvm/test/MC/AMDGPU/gfx9_asm_smem.s
126

I assume we are only interested in how instructions are getting encoded here, so no need for them to look very realistic?

llvm/test/MC/Disassembler/AMDGPU/gfx9_dasm_all.txt
10083

I too see no bracketed input bytes here, only printed ones. May this be the case that you just see them on a separate line because of the larger length of the instruction?

I thought we codegened these already? Is this missing a codegen change to use the offsets?

This intentionally misses any codegen changes, yes.

llvm/lib/Target/AMDGPU/SMInstructions.td
544

Would love some opinions on how important we think it would be to support that. If I don't miss anything, addressing this would mean either further customising AMDGPUDisassembler::getInstruction() or split the TableGen definitions for GFX8 and GFX9 -- and not just the SMEM ones. Which seems to be a significant amount of changes.

rampitec added inline comments.May 17 2022, 12:15 AM
llvm/test/MC/Disassembler/AMDGPU/gfx9_dasm_all.txt
10083

Oh, yes. This is formatting, not really brackets on input.

rampitec added inline comments.May 17 2022, 1:37 AM
llvm/test/MC/AMDGPU/gfx9_asm_smem.s
126

Isn't the final address has to be aligned, not partial offsets? I.e. this shall be fine even if we wanted to enforce something in the asm.

kosarev added inline comments.May 17 2022, 4:49 AM
llvm/test/MC/AMDGPU/gfx9_asm_smem.s
126

Yes, my understanding is that it's only the resulting address that has to be aligned.

dp added a comment.May 17 2022, 6:11 AM

Overall looks good.

llvm/lib/Target/AMDGPU/SMInstructions.td
544

// TODO: Ignore soffset_en when disassembling GFX8 instructions.

Are there cases when an illegal GFX8 code may be decoded with soffset_en=1? The _SGPR_IMM_vi case should not work for GFX8, should it?

560

This addressing mode is semantically equivalent to the one where soffset is encoded in the offset field. I'm not sure we really need it. Note that sp3 has no syntactic sugar to enforce this encoding. It may be useful for decoder, but I doubt it worth the trouble.

561

Ditto.

llvm/test/MC/AMDGPU/gfx9_asm_smem.s
63

It is a minor issue, but I noted that all your new tests use soffset=s0. It may be a good idea to avoid operands which are encoded as 0 (or add tests with other operands as well).

arsenm added inline comments.May 17 2022, 6:21 AM
llvm/test/MC/AMDGPU/gfx9_asm_smem.s
126

Yes, the final address is all that matters. But practically speaking that always means a well aligned offset (still not sure why they switched this to a byte offset)

kosarev added inline comments.May 17 2022, 7:17 AM
llvm/lib/Target/AMDGPU/SMInstructions.td
544

Not sure I read the question right, but I understand, e.g., 0xc0024141 0x00012345 (with imm=1 and soffset_en=1) should decode to s_load_dword s5, s[2:3], s0 offset:0x12345 in GFX9 and to s_load_dword s5, s[2:3], 0x12345 in GFX8. With this patch in place we fail to do the latter because our GFX8 and GFX9 definitions share the same decoding namespace; the isGFX9Only predicate for the _SGPR_IMM case below makes it non-instruction in GFX8.

560

Yes, these are not needed for codegen needs and may only be useful for disassembling. Should we leave the TODOs be until we know for sure what to do with this?

llvm/test/MC/AMDGPU/gfx9_asm_smem.s
63

Agree, and so seem to do the other tests here. I don't mind to update them all, if that's the suggestion?

dp added inline comments.May 17 2022, 8:18 AM
llvm/lib/Target/AMDGPU/SMInstructions.td
544

So after this change disassembler will be unable to decode some legal GFX8 code, correct? I think this should be avoided. Would it be difficult to amend this patch with disassembler changes to avoid this breakage?

560

Let us see what other people here think. I'd have replaced TODOs with a description of limitations of the current design. But this is a matter of taste.

llvm/test/MC/AMDGPU/gfx9_asm_smem.s
63

The file has tests with s101, m0, etc for soffset so the coverage is sufficient. I suggest to correct one new test to use e.g. s1 instead of s0.

kosarev added inline comments.May 17 2022, 8:55 AM
llvm/lib/Target/AMDGPU/SMInstructions.td
544

As there is no soffset_en in GFX8, all codes with that bit raised are not what I guess you call legal GFX8 codes. I think we would never normally produce such codes for GFX8 from codegen or assembly, but as of the moment I'm not aware of any reasons to think that such codes are actually illegal or invalid. That is basically a disassembling issue again.

kosarev updated this revision to Diff 430281.May 18 2022, 2:02 AM

Updated a test case to use a register that doesn't encode to 0.

kosarev added inline comments.May 18 2022, 2:26 AM
llvm/lib/Target/AMDGPU/SMInstructions.td
560

Tagging @foad @arsenm @rampitec for visibility.

Re replacing TODOs with descriptions: my only concern here would be to avoid masking what might be considered a real problem.

llvm/test/MC/AMDGPU/gfx9_asm_smem.s
63

Done.

Note that there are still lots of other MC tests and test cases where only s0 is used at a register position. And then on a more general note, I admit I struggle a bit to see the point in testing all possible combinations of what encoding-, diagnostics- and implementation-wise seems to be completely unrelated, such as immediate/register operands and glc modifiers, if that's the right example. Feels like removing unnecessary repetitions would make uncovered cases more visible, allow more combinations that we are truly interested in and maybe somewhat reduce testing times.

dp added inline comments.May 18 2022, 4:08 AM
llvm/lib/Target/AMDGPU/SMInstructions.td
544

You are right, this is a corner case which does not look that important. However there are third-party tools which may produce such codes, you never know. We should be able to disassemble such codes unless this requires a lot of additional work.

llvm/test/MC/AMDGPU/gfx9_asm_smem.s
63

The tests in this file have been generated by a script with the purpose of black box testing. The script did not generate all combinations of operands and modifiers, it attempted to provide at least one test for each operand kind and each modifier value. And yes, these tests are not perfect.

When working on a feature you do not have to mimic generated tests. Add a minimal set of tests which you feel would be sufficient for good coverage.

kosarev added inline comments.May 19 2022, 4:48 AM
llvm/lib/Target/AMDGPU/SMInstructions.td
544

Do we want to see it done as part of this patch? AFAIS, all the other notes are addressed.

dp added inline comments.May 19 2022, 5:10 AM
llvm/lib/Target/AMDGPU/SMInstructions.td
544

Probably a disassembler patch may be committed separately though I'd have preferred it as a part of this change.

dp accepted this revision.May 19 2022, 5:10 AM

LGTM.

This revision is now accepted and ready to land.May 19 2022, 5:10 AM
foad added inline comments.May 19 2022, 5:28 AM
llvm/lib/Target/AMDGPU/SMInstructions.td
560

I don't understand why these cases are not supported by the disassembler with the current patch. What happens if you try to disassemble them?

kosarev added inline comments.May 19 2022, 6:30 AM
llvm/lib/Target/AMDGPU/SMInstructions.td
560

It's being treated as non-instruction. Here's what I get for the example above:

; llvm-mc -filetype=obj -triple=amdgcn--amdpal -mcpu=tonga -show-encoding x.s | llvm-objdump -d --mcpu=tonga -
.text
  .long 0xc0024141, 0x00012345
0000000000000000 <.text>:
    .long 0xc0024141                                           // 000000000000: C0024141
    v_cndmask_b32_e32 v0, v69, v145, vcc                       // 000000000004: 00012345

I'm going to look into how subtarget predicates work for decoding facilities first and then as plan B maybe try something like opcode canonicalisation.

kosarev updated this revision to Diff 431052.May 20 2022, 2:21 PM

Updated to support decoding GFX8 loads matching GFX9 encodings.

kosarev added inline comments.May 20 2022, 2:24 PM
llvm/lib/Target/AMDGPU/SMInstructions.td
544

From what I see in how the TableGen's decoder backend works, it's fine to have predicated patterns that are special cases of other more generic patterns, even if the latter are themselves differently predicated. So as long as we keep our isGFX9Only instructions to be special cases of isGFX8GFX9 ones, which I think we can expect being possible, disassembling should work for GFX8 as expected. For example, replacing the soffset_en expression with let Inst{14} = !if(!and(ps.has_offset, ps.has_soffset), 1, ?); resolves the decoding issue for the GFX8 instruction mentioned above.

Will update to support the GFX9 encodings for the _SGPR loads and add tests.

kosarev updated this revision to Diff 431309.May 23 2022, 2:03 AM

Updated to support the alternative GFX9 encodings for the SGPR variants.

kosarev added inline comments.May 23 2022, 2:06 AM
llvm/lib/Target/AMDGPU/SMInstructions.td
544

Done. Please take a look.

llvm/test/MC/Disassembler/AMDGPU/gfx9_dasm_all.txt
10086–10089

...which means SP3 sees what was previously mentioned as the second alternative SGPR encoding as the usual SGPR_IMM case, so no special handling is needed here.

kosarev requested review of this revision.May 24 2022, 1:58 AM

Clearing the approval as this needs another look.

dp added inline comments.May 25 2022, 9:11 AM
llvm/lib/Target/AMDGPU/SMInstructions.td
570

Now that we have IsGFX9Specific, could not this expression be replaced with '?'

587

Ingenious!

kosarev updated this revision to Diff 432206.May 26 2022, 12:26 AM

Cleaned up the soffset field expression.

kosarev added inline comments.May 26 2022, 12:29 AM
llvm/lib/Target/AMDGPU/SMInstructions.td
570

Nice catch. Done.

587

The NonParsable bit, that's been borrowed from the Hexagon backend, so all the credit goes there!

dp accepted this revision.May 26 2022, 4:06 AM

LGTM, thanks!

This revision is now accepted and ready to land.May 26 2022, 4:06 AM
This revision was landed with ongoing or failed builds.May 26 2022, 4:46 AM
This revision was automatically updated to reflect the committed changes.