JIT: ARM64 SVE format encodings, SVE_GP_3A to SVE_HV_4A#98141
JIT: ARM64 SVE format encodings, SVE_GP_3A to SVE_HV_4A#98141TIHan merged 8 commits intodotnet:mainfrom
SVE_GP_3A to SVE_HV_4A#98141Conversation
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch Issue DetailsContributes to #94549 Adds formats:
You will notice that the instructions from format To show that it is a capstone bug, let's take the example: theEmitter->emitIns_R_R_F(INS_sve_fadd, EA_SCALABLE, REG_V0, REG_P0, 0.5,
INS_OPTS_SCALABLE_H); // FADD <Zdn>.<T>, <Pg>/M, <Zdn>.<T>, <const>This example is based on a LLVM test: JIT outputs: Notice capstone shows
|
|
@dotnet/arm64-contrib @dotnet/jit-contrib @kunalspathak @a74nh this is ready. |
Diff results for #98141Throughput diffsThroughput diffs for linux/arm64 ran on windows/x64MinOpts (-0.00% to +0.01%)
Throughput diffs for osx/arm64 ran on windows/x64MinOpts (+0.00% to +0.01%)
Throughput diffs for windows/arm64 ran on windows/x64MinOpts (-0.00% to +0.01%)
Details here |
a74nh
left a comment
There was a problem hiding this comment.
Not sure about the encodings of the imms. Everything else LGTM
src/coreclr/jit/emitarm64.cpp
Outdated
|
|
||
| if (immDbl != 0.0) | ||
| { | ||
| fpi.immFPIVal = 0; |
There was a problem hiding this comment.
For all of these the float value is one of two values. It feels heavyweight to fully encode the float. Also I'm not sure if that requires a larger instrDesc to fit in the immediate.
If it does, then alternatively we could continue to overload _idRegBit with an instrDesc::idImmBit() function. Set the bit the same way it's set in the instruction encoding.
Then all the encoding and displaying becomes simpler too.
This could also be used for the group that has a 90 or 270 immediate.
There was a problem hiding this comment.
I'm not super happy about it, but this is how we handle storing immediate floats in instrDesc. The current encode and decode functions are complicated, but using them isn't so bad.
For the 90 and 270 values, they are just like any other immediate value so I don't think we need to change that.
There was a problem hiding this comment.
Also I think here, we should encode them as 0, 1, etc. Related: #98187 (comment)
There was a problem hiding this comment.
We could as it doesn't matter too much since we have to decode them at display time, but since we already have encode/decode for immediate floats, it won't be too much different than what is already there.
There was a problem hiding this comment.
I am wondering why we need special handling for immDbl == 0.0? doesn't canEncodeFloatImm8() handle it?
There was a problem hiding this comment.
It doesn't handle 0 which is why I had to do it myself. However, since we are going to encode the rotation values as 0 - 3, I guess we should do the same here.
Agreed. Capstone is showing values that are not valid for that instruction. It's can't be your code overflowing as Looks like Capstone is just interpreting the single immediate bit incorrectly. How recent is the Capstone branch we are working from? If it's still present in HEAD, I think it would be worth raising a bug on the capstone project. |
It was from early January, I doubt this issue has been fixed. I checked their repo and no reports about it. I agree it would be good to report it. |
kunalspathak
left a comment
There was a problem hiding this comment.
With the encode change i suggested, can you double check the difference between capstone and jit?
|
@kunalspathak this is ready. I added the encodings that you suggested for the rotation values and the float constants. @amanasifkhalid This will have the encodings for the rotation values for you to use. |
Diff results for #98141Throughput diffsThroughput diffs for linux/arm64 ran on linux/x64MinOpts (-0.00% to +0.01%)
Throughput diffs for osx/arm64 ran on linux/x64MinOpts (+0.00% to +0.01%)
Throughput diffs for windows/arm64 ran on linux/x64MinOpts (-0.00% to +0.01%)
Details here |
Diff results for #98141Throughput diffsThroughput diffs for linux/arm64 ran on windows/x64MinOpts (-0.00% to +0.01%)
Throughput diffs for osx/arm64 ran on windows/x64MinOpts (+0.00% to +0.01%)
Throughput diffs for windows/arm64 ran on windows/x64MinOpts (-0.00% to +0.01%)
Details here |
|
Merging this now, only thing I changed was formatting and everything was fine before, and the build is successful with the formatting. |
Diff results for #98141Throughput diffsThroughput diffs for linux/arm64 ran on windows/x64MinOpts (-0.00% to +0.01%)
Throughput diffs for osx/arm64 ran on windows/x64MinOpts (+0.00% to +0.01%)
Throughput diffs for windows/arm64 ran on windows/x64MinOpts (-0.00% to +0.01%)
Details here |

Contributes to #94549
Adds formats:
Left: capstone,

Right: jit
You will notice that the instructions from format
SVE_HM_2A, such afadd,fsub, etc show differences of constant value between capstone and the JIT. This is a capstone bug as it is incorrectly displaying the wrong constant.To show that it is a capstone bug, let's take the example:
This example is based on a LLVM test:
JIT outputs:
fadd z0.h, p0/m, z0.h, #0.5000Capstone outputs:
00805865 fadd z0.h, p0/m, z0.h, #0.0Notice capstone shows
#0.0instead of the expected#0.5. But, when you compare the hex code with LLVM'sCHECK-ENCODING, they match.