Add Arm64 encodings for IF_SVE_AF_3A to IF_SVE_AQ_3A #95337
Conversation
dotnet-issue-labeler
bot
added
the
area-CodeGen-coreclr
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch Issue DetailsNext set of encodings to contribute towards #94549
|
|
Some of the encodings aren't yet supported by capstone. These are all quadword instructions are are not available in N2. These are untested, so the codegen code has been commented out. I've left in the code emit code for these as it should be mostly correct - but it is the job of whoever enables the codegen code to fully test it. |
|
The number of instructions in a group does not increase the time it takes to code that group. Instead, it is the uniqueness of the encoding that takes the time. This PR took me probably 4 or so hours work. There are 8 groups. So, 30mins per group. I timed one group, and that was about right. I suspect we still have some awkward encoding oddities still to come. Maybe 1 hour per group is a safer estimate going forwards. |
I don't see these 2 encodings...are you planning to add them later? |
src/coreclr/jit/codegenarm64.cpp
Outdated
|
|
||
| // IF_SVE_AG_3A | ||
| // These are not yet supported by capstone. | ||
| // theEmitter->emitIns_R_R_R(INS_sve_andqv, EA_1BYTE, REG_V4, REG_P4, REG_V4, INS_OPTS_SCALABLE_B_TO_SIMD_VECTOR); |
There was a problem hiding this comment.
can these be verified on linux gdb/lldb?
There was a problem hiding this comment.
Looks like these are not yet supported by gdb and binutils.
I've added ALL_ARM64_EMITTER_UNIT_TESTS_SVE_UNSUPPORTED in the codegen tests, plus I've added unreached() in the emit_R_R_R() for those instructions. That should prevent them from being used.
ghost
added
needs-author-action
Both of these groups only contain instructions not in capstone. I decided to move onto the next set of groups for now. I'll go back to them after this one. |
Change-Id: I068d2761af40d22f8850e64d136a81275ce4ca5f
| case IF_SVE_AI_3A: // ........xx...... ...gggnnnnnddddd -- SVE integer add reduction (predicated) | ||
| case IF_SVE_AJ_3A: // ........xx...... ...gggnnnnnddddd -- SVE integer add reduction (quadwords) | ||
| case IF_SVE_AK_3A: // ........xx...... ...gggnnnnnddddd -- SVE integer min/max reduction (predicated) | ||
| case IF_SVE_AL_3A: // ........xx...... ...gggnnnnnddddd -- SVE integer min/max reduction (quadwords) |
There was a problem hiding this comment.
Should we mix the 'n' and 'm' patterns in the same "case"? I suppose it's assuming that 'idReg3()' is either 'm' or 'n', depending on the format.
There was a problem hiding this comment.
Yes, idReg3() is the same in both.
I wasn't sure whether to keep them the same either - but, because it's the same code I went with the one block.
| emitDispSveReg(id->idReg3(), id->idInsOpt(), false); // mmmmm | ||
| break; | ||
|
|
||
| // <Vd>.<T>, <Pg>, <Zn>.<Tb> |
There was a problem hiding this comment.
This comment is very helpful. Maybe we should add them to all case "sets"?
There was a problem hiding this comment.
I've already done it for all the other SVE instructions done so far. I'm not planning on going back over NEON etc. :)
| @@ -5437,6 +5437,7 @@ void CodeGen::genProfilingLeaveCallback(unsigned helper) | |||
| // #define ALL_ARM64_EMITTER_UNIT_TESTS_GENERAL | |||
| // #define ALL_ARM64_EMITTER_UNIT_TESTS_ADVSIMD | |||
| // #define ALL_ARM64_EMITTER_UNIT_TESTS_SVE | |||
| // #define ALL_ARM64_EMITTER_UNIT_TESTS_SVE_UNSUPPORTED | |||
There was a problem hiding this comment.
not sure if it is worth adding a comment in next PR why they are not supported. "The encodings of the instructions cannot be verified currently, so are added under this flag"
| case INS_sve_andqv: | ||
| case INS_sve_eorqv: | ||
| case INS_sve_orqv: | ||
| unreached(); // TODO-SVE: Not yet supported. |
There was a problem hiding this comment.
can any of these instructions block us from the basic scenario that we are thinking of enabling?
Next set of encodings to contribute towards #94549