ARM64-SVE: refactor lsra buildHWIntrinsic #107459
Merged
+655
−755
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
dotnet-issue-labeler
bot
added
the
area-CodeGen-coreclr
dotnet-policy-service
bot
added
the
community-contribution
|
@kunalspathak - Still WIP. For now ignore anything outside of |
|
This PR is ready now. Requires #107084, #107180 and a workaround for #107537 in order for all the hwintrinsic tests to pass. Apologies, this is a large change to review, and the github diff is confused about functions I haven't touched. Probably best starting a review from the new version of I recommend this is not merged until after we've gone past the Net9 RC2 deadline. @dotnet/arm64-contrib I'll do a spmidiff next. |
|
Got some asmdiffs for the SVE tests. Spotted two differences, and one of them is due to issues in HEAD. I'll raise PRs to fix these (plus one for LoadAndInsertScalar), and then rebase this once merged. I'd like there to be no asmdiff differences in this PR |
This was referenced Sep 13, 2024
Change-Id: Id60f884b7281a9fae85a948a361511656c91357e
|
Rebased on top of the other fixes. As mentioned in #107786, fixed it so that |
|
No asm diffs now: |
kunalspathak
reviewed
Oct 1, 2024
|
|
||
| if (resultOpNum != 0) | ||
| { | ||
| embeddedDelayFreeOp = embeddedOpNode->Op(resultOpNum); |
There was a problem hiding this comment.
hhm, can you confirm if we just overwrite the embeddedDelayFreeOp that was passed as the parameter to this function?
There was a problem hiding this comment.
hhm, can you confirm if we just overwrite the
embeddedDelayFreeOpthat was passed as the parameter to this function?
Yes. the value being passed into BuildEmbeddedOperandUses() is the address of embeddedDelayFreeOp. That value can be changed within BuildEmbeddedOperandUses() and it won't effect any variables outside BuildEmbeddedOperandUses() that were also same to the same value.
I think that's what you were asking for.
|
All fixed up as suggested. |
|
I was hoping this to be zero diff, but there are still diffs related to
|
Looks like the reason for this is that in HEAD, assert(isRMW);
assert(intrin.op1->OperIs(GT_FIELD_LIST));
GenTreeFieldList* op1 = intrin.op1->AsFieldList();
assert(compiler->info.compNeedsConsecutiveRegisters);
for (GenTreeFieldList::Use& use : op1->Uses())
{
BuildDelayFreeUses(use.GetNode(), intrinsicTree);
srcCount++;
}My patch generates srcCount += BuildConsecutiveRegistersForUse(operand, delayFreeOp);
AIUI, |
With this patch there are no diffs again. It would be shame to put something so specific in this patch. |
Alright, I did some digging and turns out that for upperVectorRestore, we were not marking them as "delay-free", which this PR does.
|
sirntar
pushed a commit
to sirntar/runtime
that referenced
this pull request
Oct 8, 2024
* Add BuildConditionalSelectHWIntrinsic() * Add GetRMWOp() * Use GetDelayFreeOp() in BuildConditionalSelectWithEmbeddedOp() * simplify op2 handling * Add getVectorAddrOperand() * Add getConsecutiveRegistersOperand * Add BuildOperand() * Use BuildOperand for op1 * Add buildHWIntrinsicImmediate * Add getOperandCandidates() * Remove BuildOperand() * remove delayFreeMultiple * Fixes from other PRs to be removed * Fix formatting * Use BuildHWIntrinsicImmediate for conditional select * Remove IsRMW * Replace BuildConditionalSelectWithEmbeddedOp() with BuildEmbeddedOperandUses() * Revert "Fixes from other PRs to be removed" * Move functions * Move functions * Remove failing unary tests * Fix opNum type * Revert "Remove failing unary tests" * Remove cases from getDelayFreeOperand that are handled by default * review cleanups * Simplify masks in getOperandCandidates() * Remove IsMaskedOperation() * Check for optional embedded masks in getDelayFreeOperand * Only call BuildDelayFreeUses when register types match * Assert only on Arm64 * Comment fixups
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #104842
The logic for hwintrisics has become convoluted. Refactor it, for both SVE and AdvSimd.
Add functions to get the operand (if any) for each requirement - delay slot, consecutive registers, address, etc.
Then use a simple for loop to iterate through each operand and build depending on which requirements match for that operand.
Tested by using stress_test.py on the entire HardwareIntrinsics_Arm set.