-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JIT: ARM64 SVE format encodings, SVE_GP_3A
to SVE_HV_4A
#98141
Conversation
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also I think here, we should encode them as 0
, 1
, etc. Related: #98187 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am wondering why we need special handling for immDbl == 0.0
? doesn't canEncodeFloatImm8()
handle it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Thanks!
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.5000
Capstone outputs:
00805865 fadd z0.h, p0/m, z0.h, #0.0
Notice capstone shows
#0.0
instead of the expected#0.5
. But, when you compare the hex code with LLVM'sCHECK-ENCODING
, they match.