[AMDGPU][MC] Create tests for VOP3 True16

[Sisyph]

For the upcoming support of VOP3 encoded instructions with 16 bit operands referencing hi register halves on GFX11 (part of True16), we need assembler and disassembler tests.

This includes:

• VOP1,2,C promoted to VOP3
• dpp & dpp8 versions of the VOP3 instructions
• Tests for hi and lo halves of VGPRs

[llvmbot]

@llvm/issue-subscribers-backend-amdgpu

[dpreobra]

Sure. What is the deadline?

[Sisyph]

Sure. What is the deadline?

Thanks! Does Nov 4 seem reasonable?

[dpreobra]

It looks doable.

[dpreobra]

Please let me know if I understood you correctly:

• These tests shall use .h/.l suffices instead of op_sel modifier.
• These tests shall not specify op_sel modifier. (Another option is to specify both suffices and op_sel.)
• These tests may include SGPR operands; in this case op_sel must be set to 0 for these operands. (Another option is to disable tests with SGPRs specified for 16 bit operands.)

dpp & dpp8 versions of the VOP3 instructions

Do you mean only promoted opcodes?

[Sisyph]

Please let me know if I understood you correctly:

* These tests shall use `.h/.l` suffices _instead of_ `op_sel` modifier.

Correct.

* These tests shall not specify `op_sel` modifier. (Another option is to specify both suffices and `op_sel`.)

Correct.
I have not yet determined whether the op_sel operand should be allowed on true16 instructions as an alternative. The current tests in tree using op_sel can be considered tests for that behavior, so new ones are not needed. I believe there is no benefit to allowing both .l/.h suffices and the op_sel operand simultaneously. In particular because they could conflict.
I suppose I will want to test what happens when both are present, and make that an assembly error.
I plan for VOP3P to still use op_sel. This will be consistent with sp3

* These tests may include SGPR operands; in this case `op_sel` must be set to 0 for these operands. (Another option is to disable tests with SGPRs specified for 16 bit operands.)

This is an interesting point. Certainly I would not require an assembly op_sel operand if an SGPR operand is specificed, and I would set the op_sel bit in the encoding to 0 by default.

Why do you think op_sel must be 0 for SGPRs? For example, sp3 will accept the following
v_min3_f16 v5.h, sel_hi(v1), v0, s2.h dpp8:[7,6,5,4,3,2,1,0]
I'm not sure of op_sel operates differently for VOP3P than for VOP3, but for VOP3P the docs state "OPSEL works for 16-bit VGPR, SGPR and literal-constant sources; for inline constant sources OPSEL must be zero"

But I haven't considered yet if we can or should support that syntax (i.e. s2.h) in llvm and what it would do.

dpp & dpp8 versions of the VOP3 instructions

Do you mean only promoted opcodes?

I'm not exactly sure what your question means, but I would like tests for native VOP3 and VOP1/2/C promoted to VOP3, without dpp, with dpp16, and with dpp8.
I already have tests for true16 VOP1, VOP2, and VOPC with and without dpp and dpp8 which you supplied.

[dpreobra]

Why do you think op_sel must be 0 for SGPRs?

I’m sorry, my questions were ambiguous. I contemplated different possibilities in test generation, that’s all. My impression was that you had no support for 16-bit SGPRs. SP3 seems to allow that (with exceptions).

I just want to know how you would like to handle 16 bit SGPRs and could tests include them.

v_min3_f16 v5.h, v1.h, v0.l, s2 dpp8:[7,6,5,4,3,2,1,0]

Should tests include something like this?

VOP1,2,C promoted to VOP3
dpp & dpp8 versions of the VOP3 instructions

Looking at this description I decided you only wanted promoted VOP3, so I asked if tests for dpp should only include promoted opcodes. Looks like it was a misunderstanding, tests for VOP3/VOP3_DPP8/VOP3_DPP16 shall be for both native and promoted opcodes.

[Sisyph]

I just want to know how you would like to handle 16 bit SGPRs and could tests include them.

v_min3_f16 v5.h, v1.h, v0.l, s2 dpp8:[7,6,5,4,3,2,1,0]

Should tests include something like this?

Yes, that would be a good test.

However, I wouldn't want the following test, because I don't know what to do with the hi half of an SGPR
v_min3_f16 v5.h, v1.h, v0.l, s2.h dpp8:[7,6,5,4,3,2,1,0]

VOP1,2,C promoted to VOP3
dpp & dpp8 versions of the VOP3 instructions

Looking at this description I decided you only wanted promoted VOP3, so I asked if tests for dpp should only include promoted opcodes. Looks like it was a misunderstanding, tests for VOP3/VOP3_DPP8/VOP3_DPP16 shall be for both native and promoted opcodes.

Great, thanks.

[dpreobra]

I've updated test generator and started testing the results. There are some issues which I'm not sure how to handle.

First, many 16-bit VOP3 opcodes do not currently support op_sel (but they should). These include all True16 opcodes promoted from VOP1/VOP2/VOPC and some native VOP3 opcodes (v_ashrrev_i16, v_max_i16, etc.). For these opcodes there will be tests with .l and no tests with .h. Is this what you expect?

Second, there are opcodes with 16 bit operands which are incorrectly defined in llvm as b32. Known cases are:

• v_alignbit_b32
• v_alignbyte_b32
• v_cmp_class_f16_e64
• v_cmpx_class_f16_e64

There may be other opcodes with similar issues, but my test scripts cannot detect these cases automatically.

For known cases like v_alignbit_b32 tests will have no .l/.h suffices. For unknown cases tests will have .l/.h suffices for some operands, but assembler will fail on these. It this acceptable?

[Sisyph]

These are great findings!

I've updated test generator and started testing the results. There are some issues which I'm not sure how to handle.

First, many 16-bit VOP3 opcodes do not currently support op_sel (but they should). These include all True16 opcodes promoted from VOP1/VOP2/VOPC and some native VOP3 opcodes (v_ashrrev_i16, v_max_i16, etc.). For these opcodes there will be tests with .l and no tests with .h. Is this what you expect?

I would like to add op_sel support for those instructions either immediately or in the medium term if it is unexpectedly complex.
The best case for what you would provide is two sets of test. One which passes with current op_sel support ( only test with .l) and a second set with the .h tests.

Second, there are opcodes with 16 bit operands which are incorrectly defined in llvm as b32. Known cases are:

* v_alignbit_b32

* v_alignbyte_b32

* v_cmp_class_f16_e64

* v_cmpx_class_f16_e64

There may be other opcodes with similar issues, but my test scripts cannot detect these cases automatically.

For known cases like v_alignbit_b32 tests will have no .l/.h suffices. For unknown cases tests will have .l/.h suffices for some operands, but assembler will fail on these. It this acceptable?

The assembler failing on those sounds good.
I would like to correct those instructions to use 16-bit operands if possible. Failing tests will be a good way for me to discover the affected ones. In addition, if you are emitting test with no suffices for any known cases in addition to the above please let me know.

[dpreobra]

The best case for what you would provide is two sets of test. One which passes with current op_sel support ( only test with .l) and a second set with the .h tests.

Sure. I have an option to generate tests for each instruction in a separate file. If it is more convenient for you, I can provide set#2 as separate files. Running these tests will immediately indicate instructions with missing or problematic op_sel support.

[dpreobra]

In addition, if you are emitting test with no suffices for any known cases in addition to the above please let me know.

There is another special case I forgot about: v_permlane16_b32 and v_permlanex16_b32. They have 32 bit operands but op_sel modifier is enabled to indicate DPP bound_ctrl and fi. I think tests for permlane require no changes for now. We should consider switching to SP3 syntax in the future.