-
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
[Arm64] ASIMD Implement widening, narrowing, saturating instructions #35379
[Arm64] ASIMD Implement widening, narrowing, saturating instructions #35379
Conversation
…p emitfmtsarm64.h
…mt == insFmt) in emitarm64.cpp
… ssubl{2}, ssubw{2}, uabal{2}, uabdl{2}, uaddl{2}, uaddw{2}, umlal{2}, umlsl{2}, usubl{2}, usubw{2} in emitarm64.cpp
…in emitter::emitIns_R_R_R_I in emitarm64.cpp
…Ins_R_R_R in emitarm64.cpp
…arm64.cpp emitarm64.cpp emitfmtsarm64.h
case IF_BI_0B: | ||
case IF_BI_0C: | ||
case IF_BI_1A: | ||
case IF_BI_1B: |
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.
@BruceForstall @briansull Do you know why this giant sequence of case-s is needed? It's obviously not checking if fmt
argument passed from outside (i.e. from one of the emitIns_X_Y_Z functions) matches the instruction format specified in INST1() in hwintrinsiclistarm64.h table. If someone makes a mistake in this table - it will go unnoticed (it happened to me yesterday). I believe it is better to replace this with the following logic in default:
Thoughts?
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.
This seems reasonable to me. I guess the idea here is that for INST1, there is exactly one fmt. For INST2+, there is a "pseudo-format" in the "fmt" part of the macro that then maps to the actual format.
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.
The ones named here were all of the formats that only had one possible formats. This switch insures that you properly update this method when adding new instr formats. With your change the assumption is made that a newly added instrFormat is an INST1 case by default. Where as before your chanfge it would assert on the newly added format.
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.
But after looking into your change I believe that what you have added here will also work fine.
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.
The ones named here were all of the formats that only had one possible formats. This switch insures that you properly update this method when adding new instr formats. With your change the assumption is made that a newly added instrFormat is an INST1 case by default. Where as before your chanfge it would assert on the newly added format.
That would assert only if you haven't added a new format and set fmt to the same value in one of emitIns_X_Y_Z functions. But if the latter is false (i.e. the function returns wrong format) then it wouldn't assert.
After this change it is not longer required to update this switch and it will automatically check that the fmt
set in emitIns is consistent with the one declared in instrsarm64.h table.
@@ -7864,6 +7858,40 @@ void CodeGen::genArm64EmitterUnitTests() | |||
theEmitter->emitIns_R_R(INS_fcvtn2, EA_8BYTE, REG_V0, REG_V1); | |||
#endif | |||
|
|||
#ifdef ALL_ARM64_EMITTER_UNIT_TESTS | |||
// sadalp vector | |||
theEmitter->emitIns_R_R(INS_sadalp, EA_8BYTE, REG_V0, REG_V1, INS_OPTS_8B); |
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.
These are a little odd because Vd and Vn take different arrangement specifiers, even though one implies the other. So which register does this insOpts specifier refer to? There must be other SIMD instructions like this as well. Should we have a function that takes two, and asserts they are as expected (e.g., if we have Vd.4H then we have Vn.8B)?
Are there instructions where the two specifies can both be arbitrary (and unrelated)?
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 would say most of the added "long" instructions (except high narrow - addhn{2}, subhn{2}) specify their source register(s) arrangement specifiers.
I don't think we want to specify two arrangements when emitting at the moment - this would complicate the logic in the intrinsic backend - you would not only need to infer the insOpts from an incoming argument/return value but also to compute the second arrangement somehow.
Are there instructions where the two specifies can both be arbitrary (and unrelated)?
I have not seen such instructions - I hope there won't be any
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
case IF_BI_0B: | ||
case IF_BI_0C: | ||
case IF_BI_1A: | ||
case IF_BI_1B: |
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.
The ones named here were all of the formats that only had one possible formats. This switch insures that you properly update this method when adding new instr formats. With your change the assumption is made that a newly added instrFormat is an INST1 case by default. Where as before your chanfge it would assert on the newly added format.
case IF_BI_0B: | ||
case IF_BI_0C: | ||
case IF_BI_1A: | ||
case IF_BI_1B: |
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.
But after looking into your change I believe that what you have added here will also work fine.
…s in emitarm64.cpp
…sts() in codegenarm64.cpp
Last commits are:
|
Adds new instructions for #32512 #35143
Also fixes #35303
Attached are jitDisasm and WinDbg u command outputs.
jitDisasm
WinDbg(u)