-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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: Build and consume FMA and Permute node operands in standard order #103100
Conversation
The building and consumption of these operands can happen in op1, op2, op3 order regardless of whether the codegen uses the registers in a different order. Fix dotnet#102773
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch |
{ | ||
srcCount += op->isContained() ? BuildOperandUses(op) : BuildDelayFreeUses(op, emitOp1); | ||
} | ||
} |
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 could probably be cleaned up to just build the uses directly without first figuring out emitOp1, emitOp2, emitOp3
, but I didn't really understand all the constraints around copiesUpperBits
, the preferred target and the contained operand, so I gave up on trying to do it.
cc @dotnet/jit-contrib PTAL @kunalspathak @tannergooding This should hopefully fix the failures for good this time. |
@jakobbotsch there's another case that is doing something similar with operand switching for |
We also, more generally have various commutative nodes that also dynamically pick the |
Ah, good catch, same thing should be applied there. Pushed it to this PR.
Yeah, that looks fine. Seems likely we could try to clean up/unify some of these cases. |
The building and consumption of these operands can happen in op1, op2, op3 order regardless of whether the codegen uses the registers in a different order.
Fix #102773