JIT: Build and consume FMA and Permute node operands in standard order by jakobbotsch · Pull Request #103100 · dotnet/runtime

jakobbotsch · 2024-06-05T22:41:47Z

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

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. Fixdotnet#102773

dotnet-policy-service · 2024-06-05T22:42:11Z

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

jakobbotsch · 2024-06-06T00:01:58Z

+ {
+ srcCount += op->isContained() ? BuildOperandUses(op) : BuildDelayFreeUses(op, emitOp1);
+ }
+ }


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.

jakobbotsch · 2024-06-06T03:01:37Z

cc @dotnet/jit-contrib PTAL @kunalspathak @tannergooding

This should hopefully fix the failures for good this time.

tannergooding · 2024-06-06T04:07:20Z

@jakobbotsch there's another case that is doing something similar with operand switching for PermuteVar*x2, I'm guessing it needs an identical fix?

tannergooding · 2024-06-06T04:10:33Z

We also, more generally have various commutative nodes that also dynamically pick the tgtPrefUse and containable node via logic in BuildRMWUses. These ones look fine because they look to always build op1 then op2 and codegen (such as genCodeForBinary) then consumes them in the same order via genConsumeOperands even if codegen is going to swap them about

jakobbotsch · 2024-06-06T15:16:27Z

@jakobbotsch there's another case that is doing something similar with operand switching for PermuteVar*x2, I'm guessing it needs an identical fix?

Ah, good catch, same thing should be applied there. Pushed it to this PR.

We also, more generally have various commutative nodes that also dynamically pick the tgtPrefUse and containable node via logic in BuildRMWUses. These ones look fine because they look to always build op1 then op2 and codegen (such as genCodeForBinary) then consumes them in the same order via genConsumeOperands even if codegen is going to swap them about

Yeah, that looks fine. Seems likely we could try to clean up/unify some of these cases.

jakobbotsch · 2024-06-06T17:54:14Z

No diffs

jakobbotsch · 2024-06-05T22:41:47Z

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

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. Fixdotnet#102773

dotnet-policy-service · 2024-06-05T22:42:11Z

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

jakobbotsch · 2024-06-06T00:01:58Z

+ {
+ srcCount += op->isContained() ? BuildOperandUses(op) : BuildDelayFreeUses(op, emitOp1);
+ }
+ }


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.

jakobbotsch · 2024-06-06T03:01:37Z

cc @dotnet/jit-contrib PTAL @kunalspathak @tannergooding

This should hopefully fix the failures for good this time.

tannergooding · 2024-06-06T04:07:20Z

@jakobbotsch there's another case that is doing something similar with operand switching for PermuteVar*x2, I'm guessing it needs an identical fix?

tannergooding · 2024-06-06T04:10:33Z

We also, more generally have various commutative nodes that also dynamically pick the tgtPrefUse and containable node via logic in BuildRMWUses. These ones look fine because they look to always build op1 then op2 and codegen (such as genCodeForBinary) then consumes them in the same order via genConsumeOperands even if codegen is going to swap them about

jakobbotsch · 2024-06-06T15:16:27Z

@jakobbotsch there's another case that is doing something similar with operand switching for PermuteVar*x2, I'm guessing it needs an identical fix?

Ah, good catch, same thing should be applied there. Pushed it to this PR.

We also, more generally have various commutative nodes that also dynamically pick the tgtPrefUse and containable node via logic in BuildRMWUses. These ones look fine because they look to always build op1 then op2 and codegen (such as genCodeForBinary) then consumes them in the same order via genConsumeOperands even if codegen is going to swap them about

Yeah, that looks fine. Seems likely we could try to clean up/unify some of these cases.

jakobbotsch · 2024-06-06T17:54:14Z

No diffs

jakobbotsch · 2024-06-05T22:41:47Z

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

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. Fixdotnet#102773

dotnet-policy-service · 2024-06-05T22:42:11Z

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

jakobbotsch · 2024-06-06T00:01:58Z

+ {
+ srcCount += op->isContained() ? BuildOperandUses(op) : BuildDelayFreeUses(op, emitOp1);
+ }
+ }


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.

jakobbotsch · 2024-06-06T03:01:37Z

cc @dotnet/jit-contrib PTAL @kunalspathak @tannergooding

This should hopefully fix the failures for good this time.

tannergooding · 2024-06-06T04:07:20Z

@jakobbotsch there's another case that is doing something similar with operand switching for PermuteVar*x2, I'm guessing it needs an identical fix?

tannergooding · 2024-06-06T04:10:33Z

We also, more generally have various commutative nodes that also dynamically pick the tgtPrefUse and containable node via logic in BuildRMWUses. These ones look fine because they look to always build op1 then op2 and codegen (such as genCodeForBinary) then consumes them in the same order via genConsumeOperands even if codegen is going to swap them about

jakobbotsch · 2024-06-06T15:16:27Z

@jakobbotsch there's another case that is doing something similar with operand switching for PermuteVar*x2, I'm guessing it needs an identical fix?

Ah, good catch, same thing should be applied there. Pushed it to this PR.

We also, more generally have various commutative nodes that also dynamically pick the tgtPrefUse and containable node via logic in BuildRMWUses. These ones look fine because they look to always build op1 then op2 and codegen (such as genCodeForBinary) then consumes them in the same order via genConsumeOperands even if codegen is going to swap them about

Yeah, that looks fine. Seems likely we could try to clean up/unify some of these cases.

jakobbotsch · 2024-06-06T17:54:14Z

No diffs

jakobbotsch · 2024-06-05T22:41:47Z

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

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. Fixdotnet#102773

dotnet-policy-service · 2024-06-05T22:42:11Z

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

jakobbotsch · 2024-06-06T00:01:58Z

+ {
+ srcCount += op->isContained() ? BuildOperandUses(op) : BuildDelayFreeUses(op, emitOp1);
+ }
+ }


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.

jakobbotsch · 2024-06-06T03:01:37Z

cc @dotnet/jit-contrib PTAL @kunalspathak @tannergooding

This should hopefully fix the failures for good this time.

tannergooding · 2024-06-06T04:07:20Z

@jakobbotsch there's another case that is doing something similar with operand switching for PermuteVar*x2, I'm guessing it needs an identical fix?

tannergooding · 2024-06-06T04:10:33Z

We also, more generally have various commutative nodes that also dynamically pick the tgtPrefUse and containable node via logic in BuildRMWUses. These ones look fine because they look to always build op1 then op2 and codegen (such as genCodeForBinary) then consumes them in the same order via genConsumeOperands even if codegen is going to swap them about

jakobbotsch · 2024-06-06T15:16:27Z

@jakobbotsch there's another case that is doing something similar with operand switching for PermuteVar*x2, I'm guessing it needs an identical fix?

Ah, good catch, same thing should be applied there. Pushed it to this PR.

We also, more generally have various commutative nodes that also dynamically pick the tgtPrefUse and containable node via logic in BuildRMWUses. These ones look fine because they look to always build op1 then op2 and codegen (such as genCodeForBinary) then consumes them in the same order via genConsumeOperands even if codegen is going to swap them about

Yeah, that looks fine. Seems likely we could try to clean up/unify some of these cases.

jakobbotsch · 2024-06-06T17:54:14Z

No diffs

jakobbotsch · 2024-06-05T22:41:47Z

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

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. Fixdotnet#102773

dotnet-policy-service · 2024-06-05T22:42:11Z

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

jakobbotsch · 2024-06-06T00:01:58Z

+ {
+ srcCount += op->isContained() ? BuildOperandUses(op) : BuildDelayFreeUses(op, emitOp1);
+ }
+ }


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.

jakobbotsch · 2024-06-06T03:01:37Z

cc @dotnet/jit-contrib PTAL @kunalspathak @tannergooding

This should hopefully fix the failures for good this time.

tannergooding · 2024-06-06T04:07:20Z

@jakobbotsch there's another case that is doing something similar with operand switching for PermuteVar*x2, I'm guessing it needs an identical fix?

tannergooding · 2024-06-06T04:10:33Z

We also, more generally have various commutative nodes that also dynamically pick the tgtPrefUse and containable node via logic in BuildRMWUses. These ones look fine because they look to always build op1 then op2 and codegen (such as genCodeForBinary) then consumes them in the same order via genConsumeOperands even if codegen is going to swap them about

jakobbotsch · 2024-06-06T15:16:27Z

@jakobbotsch there's another case that is doing something similar with operand switching for PermuteVar*x2, I'm guessing it needs an identical fix?

Ah, good catch, same thing should be applied there. Pushed it to this PR.

We also, more generally have various commutative nodes that also dynamically pick the tgtPrefUse and containable node via logic in BuildRMWUses. These ones look fine because they look to always build op1 then op2 and codegen (such as genCodeForBinary) then consumes them in the same order via genConsumeOperands even if codegen is going to swap them about

Yeah, that looks fine. Seems likely we could try to clean up/unify some of these cases.

jakobbotsch · 2024-06-06T17:54:14Z

No diffs

jakobbotsch · 2024-06-05T22:41:47Z

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

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. Fixdotnet#102773

dotnet-policy-service · 2024-06-05T22:42:11Z

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

jakobbotsch · 2024-06-06T00:01:58Z

+ {
+ srcCount += op->isContained() ? BuildOperandUses(op) : BuildDelayFreeUses(op, emitOp1);
+ }
+ }


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.

jakobbotsch · 2024-06-06T03:01:37Z

cc @dotnet/jit-contrib PTAL @kunalspathak @tannergooding

This should hopefully fix the failures for good this time.

tannergooding · 2024-06-06T04:07:20Z

@jakobbotsch there's another case that is doing something similar with operand switching for PermuteVar*x2, I'm guessing it needs an identical fix?

tannergooding · 2024-06-06T04:10:33Z

We also, more generally have various commutative nodes that also dynamically pick the tgtPrefUse and containable node via logic in BuildRMWUses. These ones look fine because they look to always build op1 then op2 and codegen (such as genCodeForBinary) then consumes them in the same order via genConsumeOperands even if codegen is going to swap them about

jakobbotsch · 2024-06-06T15:16:27Z

@jakobbotsch there's another case that is doing something similar with operand switching for PermuteVar*x2, I'm guessing it needs an identical fix?

Ah, good catch, same thing should be applied there. Pushed it to this PR.

We also, more generally have various commutative nodes that also dynamically pick the tgtPrefUse and containable node via logic in BuildRMWUses. These ones look fine because they look to always build op1 then op2 and codegen (such as genCodeForBinary) then consumes them in the same order via genConsumeOperands even if codegen is going to swap them about

Yeah, that looks fine. Seems likely we could try to clean up/unify some of these cases.

jakobbotsch · 2024-06-06T17:54:14Z

No diffs

jakobbotsch · 2024-06-05T22:41:47Z

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

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. Fixdotnet#102773

dotnet-policy-service · 2024-06-05T22:42:11Z

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

jakobbotsch · 2024-06-06T00:01:58Z

+ {
+ srcCount += op->isContained() ? BuildOperandUses(op) : BuildDelayFreeUses(op, emitOp1);
+ }
+ }


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.

jakobbotsch · 2024-06-06T03:01:37Z

cc @dotnet/jit-contrib PTAL @kunalspathak @tannergooding

This should hopefully fix the failures for good this time.

tannergooding · 2024-06-06T04:07:20Z

@jakobbotsch there's another case that is doing something similar with operand switching for PermuteVar*x2, I'm guessing it needs an identical fix?

tannergooding · 2024-06-06T04:10:33Z

We also, more generally have various commutative nodes that also dynamically pick the tgtPrefUse and containable node via logic in BuildRMWUses. These ones look fine because they look to always build op1 then op2 and codegen (such as genCodeForBinary) then consumes them in the same order via genConsumeOperands even if codegen is going to swap them about

jakobbotsch · 2024-06-06T15:16:27Z

@jakobbotsch there's another case that is doing something similar with operand switching for PermuteVar*x2, I'm guessing it needs an identical fix?

Ah, good catch, same thing should be applied there. Pushed it to this PR.

We also, more generally have various commutative nodes that also dynamically pick the tgtPrefUse and containable node via logic in BuildRMWUses. These ones look fine because they look to always build op1 then op2 and codegen (such as genCodeForBinary) then consumes them in the same order via genConsumeOperands even if codegen is going to swap them about

Yeah, that looks fine. Seems likely we could try to clean up/unify some of these cases.

jakobbotsch · 2024-06-06T17:54:14Z

No diffs

jakobbotsch · 2024-06-05T22:41:47Z

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

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. Fixdotnet#102773

dotnet-policy-service · 2024-06-05T22:42:11Z

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

jakobbotsch · 2024-06-06T00:01:58Z

+ {
+ srcCount += op->isContained() ? BuildOperandUses(op) : BuildDelayFreeUses(op, emitOp1);
+ }
+ }


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.

jakobbotsch · 2024-06-06T03:01:37Z

cc @dotnet/jit-contrib PTAL @kunalspathak @tannergooding

This should hopefully fix the failures for good this time.

tannergooding · 2024-06-06T04:07:20Z

@jakobbotsch there's another case that is doing something similar with operand switching for PermuteVar*x2, I'm guessing it needs an identical fix?

tannergooding · 2024-06-06T04:10:33Z

We also, more generally have various commutative nodes that also dynamically pick the tgtPrefUse and containable node via logic in BuildRMWUses. These ones look fine because they look to always build op1 then op2 and codegen (such as genCodeForBinary) then consumes them in the same order via genConsumeOperands even if codegen is going to swap them about

jakobbotsch · 2024-06-06T15:16:27Z

@jakobbotsch there's another case that is doing something similar with operand switching for PermuteVar*x2, I'm guessing it needs an identical fix?

Ah, good catch, same thing should be applied there. Pushed it to this PR.

We also, more generally have various commutative nodes that also dynamically pick the tgtPrefUse and containable node via logic in BuildRMWUses. These ones look fine because they look to always build op1 then op2 and codegen (such as genCodeForBinary) then consumes them in the same order via genConsumeOperands even if codegen is going to swap them about

Yeah, that looks fine. Seems likely we could try to clean up/unify some of these cases.

jakobbotsch · 2024-06-06T17:54:14Z

No diffs

JIT: Build and consume FMA node operands in standard order
b0b1dcd
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. Fixdotnet#102773

ghost added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Jun 5, 2024

dotnet-policy-serviceBot assigned jakobbotsch Jun 5, 2024

jakobbotsch added 2 commits June 6, 2024 01:28

Handle resultOpNum == 0
f4b6fd9

Base it on the old code
c36103c

jakobbotsch commented Jun 6, 2024
View reviewed changes

jakobbotsch marked this pull request as ready for review June 6, 2024 03:00

jakobbotsch requested review from kunalspathak and tannergooding June 6, 2024 03:01

tannergooding approved these changes Jun 6, 2024
View reviewed changes

Apply same fix to Permute intrinsics
d6bbc45

jakobbotsch changed the title ~~JIT: Build and consume FMA node operands in standard order~~JIT: Build and consume FMA and Permute node operands in standard orderJun 6, 2024

tannergooding approved these changes Jun 6, 2024
View reviewed changes

jakobbotsch merged commit f6a7ebb into dotnet:mainJun 6, 2024

jakobbotsch deleted the refix-102773 branch June 6, 2024 22:07

github-actionsBot locked and limited conversation to collaborators Jul 7, 2024

JIT: Build and consume FMA node operands in standard order
b0b1dcd
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. Fixdotnet#102773

ghost added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Jun 5, 2024

dotnet-policy-serviceBot assigned jakobbotsch Jun 5, 2024

jakobbotsch added 2 commits June 6, 2024 01:28

Handle resultOpNum == 0
f4b6fd9

Base it on the old code
c36103c

jakobbotsch commented Jun 6, 2024
View reviewed changes

jakobbotsch marked this pull request as ready for review June 6, 2024 03:00

jakobbotsch requested review from kunalspathak and tannergooding June 6, 2024 03:01

tannergooding approved these changes Jun 6, 2024
View reviewed changes

Apply same fix to Permute intrinsics
d6bbc45

jakobbotsch changed the title ~~JIT: Build and consume FMA node operands in standard order~~JIT: Build and consume FMA and Permute node operands in standard orderJun 6, 2024

tannergooding approved these changes Jun 6, 2024
View reviewed changes

jakobbotsch merged commit f6a7ebb into dotnet:mainJun 6, 2024

jakobbotsch deleted the refix-102773 branch June 6, 2024 22:07

github-actionsBot locked and limited conversation to collaborators Jul 7, 2024

JIT: Build and consume FMA node operands in standard order
b0b1dcd
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. Fixdotnet#102773

ghost added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Jun 5, 2024

dotnet-policy-serviceBot assigned jakobbotsch Jun 5, 2024

jakobbotsch added 2 commits June 6, 2024 01:28

Handle resultOpNum == 0
f4b6fd9

Base it on the old code
c36103c

jakobbotsch commented Jun 6, 2024
View reviewed changes

jakobbotsch marked this pull request as ready for review June 6, 2024 03:00

jakobbotsch requested review from kunalspathak and tannergooding June 6, 2024 03:01

tannergooding approved these changes Jun 6, 2024
View reviewed changes

Apply same fix to Permute intrinsics
d6bbc45

jakobbotsch changed the title ~~JIT: Build and consume FMA node operands in standard order~~JIT: Build and consume FMA and Permute node operands in standard orderJun 6, 2024

tannergooding approved these changes Jun 6, 2024
View reviewed changes

jakobbotsch merged commit f6a7ebb into dotnet:mainJun 6, 2024

jakobbotsch deleted the refix-102773 branch June 6, 2024 22:07

github-actionsBot locked and limited conversation to collaborators Jul 7, 2024

JIT: Build and consume FMA node operands in standard order
b0b1dcd
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. Fixdotnet#102773

ghost added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Jun 5, 2024

dotnet-policy-serviceBot assigned jakobbotsch Jun 5, 2024

jakobbotsch added 2 commits June 6, 2024 01:28

Handle resultOpNum == 0
f4b6fd9

Base it on the old code
c36103c

jakobbotsch commented Jun 6, 2024
View reviewed changes

jakobbotsch marked this pull request as ready for review June 6, 2024 03:00

jakobbotsch requested review from kunalspathak and tannergooding June 6, 2024 03:01

tannergooding approved these changes Jun 6, 2024
View reviewed changes

Apply same fix to Permute intrinsics
d6bbc45

jakobbotsch changed the title ~~JIT: Build and consume FMA node operands in standard order~~JIT: Build and consume FMA and Permute node operands in standard orderJun 6, 2024

tannergooding approved these changes Jun 6, 2024
View reviewed changes

jakobbotsch merged commit f6a7ebb into dotnet:mainJun 6, 2024

jakobbotsch deleted the refix-102773 branch June 6, 2024 22:07

github-actionsBot locked and limited conversation to collaborators Jul 7, 2024

JIT: Build and consume FMA node operands in standard order
b0b1dcd
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. Fixdotnet#102773

ghost added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Jun 5, 2024

dotnet-policy-serviceBot assigned jakobbotsch Jun 5, 2024

jakobbotsch added 2 commits June 6, 2024 01:28

Handle resultOpNum == 0
f4b6fd9

Base it on the old code
c36103c

jakobbotsch commented Jun 6, 2024
View reviewed changes

jakobbotsch marked this pull request as ready for review June 6, 2024 03:00

jakobbotsch requested review from kunalspathak and tannergooding June 6, 2024 03:01

tannergooding approved these changes Jun 6, 2024
View reviewed changes

Apply same fix to Permute intrinsics
d6bbc45

jakobbotsch changed the title ~~JIT: Build and consume FMA node operands in standard order~~JIT: Build and consume FMA and Permute node operands in standard orderJun 6, 2024

tannergooding approved these changes Jun 6, 2024
View reviewed changes

jakobbotsch merged commit f6a7ebb into dotnet:mainJun 6, 2024

jakobbotsch deleted the refix-102773 branch June 6, 2024 22:07

github-actionsBot locked and limited conversation to collaborators Jul 7, 2024

JIT: Build and consume FMA node operands in standard order
b0b1dcd
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. Fixdotnet#102773

ghost added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Jun 5, 2024

dotnet-policy-serviceBot assigned jakobbotsch Jun 5, 2024

jakobbotsch added 2 commits June 6, 2024 01:28

Handle resultOpNum == 0
f4b6fd9

Base it on the old code
c36103c

jakobbotsch commented Jun 6, 2024
View reviewed changes

jakobbotsch marked this pull request as ready for review June 6, 2024 03:00

jakobbotsch requested review from kunalspathak and tannergooding June 6, 2024 03:01

tannergooding approved these changes Jun 6, 2024
View reviewed changes

Apply same fix to Permute intrinsics
d6bbc45

jakobbotsch changed the title ~~JIT: Build and consume FMA node operands in standard order~~JIT: Build and consume FMA and Permute node operands in standard orderJun 6, 2024

tannergooding approved these changes Jun 6, 2024
View reviewed changes

jakobbotsch merged commit f6a7ebb into dotnet:mainJun 6, 2024

jakobbotsch deleted the refix-102773 branch June 6, 2024 22:07

github-actionsBot locked and limited conversation to collaborators Jul 7, 2024

JIT: Build and consume FMA node operands in standard order
b0b1dcd
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. Fixdotnet#102773

ghost added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Jun 5, 2024

dotnet-policy-serviceBot assigned jakobbotsch Jun 5, 2024

jakobbotsch added 2 commits June 6, 2024 01:28

Handle resultOpNum == 0
f4b6fd9

Base it on the old code
c36103c

jakobbotsch commented Jun 6, 2024
View reviewed changes

jakobbotsch marked this pull request as ready for review June 6, 2024 03:00

jakobbotsch requested review from kunalspathak and tannergooding June 6, 2024 03:01

tannergooding approved these changes Jun 6, 2024
View reviewed changes

Apply same fix to Permute intrinsics
d6bbc45

jakobbotsch changed the title ~~JIT: Build and consume FMA node operands in standard order~~JIT: Build and consume FMA and Permute node operands in standard orderJun 6, 2024

tannergooding approved these changes Jun 6, 2024
View reviewed changes

jakobbotsch merged commit f6a7ebb into dotnet:mainJun 6, 2024

jakobbotsch deleted the refix-102773 branch June 6, 2024 22:07

github-actionsBot locked and limited conversation to collaborators Jul 7, 2024

JIT: Build and consume FMA node operands in standard order
b0b1dcd
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. Fixdotnet#102773

ghost added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Jun 5, 2024

dotnet-policy-serviceBot assigned jakobbotsch Jun 5, 2024

jakobbotsch added 2 commits June 6, 2024 01:28

Handle resultOpNum == 0
f4b6fd9

Base it on the old code
c36103c

jakobbotsch commented Jun 6, 2024
View reviewed changes

jakobbotsch marked this pull request as ready for review June 6, 2024 03:00

jakobbotsch requested review from kunalspathak and tannergooding June 6, 2024 03:01

tannergooding approved these changes Jun 6, 2024
View reviewed changes

Apply same fix to Permute intrinsics
d6bbc45

jakobbotsch changed the title ~~JIT: Build and consume FMA node operands in standard order~~JIT: Build and consume FMA and Permute node operands in standard orderJun 6, 2024

tannergooding approved these changes Jun 6, 2024
View reviewed changes

jakobbotsch merged commit f6a7ebb into dotnet:mainJun 6, 2024

jakobbotsch deleted the refix-102773 branch June 6, 2024 22:07

github-actionsBot locked and limited conversation to collaborators Jul 7, 2024

Uh oh!

Conversation

jakobbotsch commented Jun 5, 2024

Uh oh!

dotnet-policy-serviceBot commented Jun 5, 2024

Uh oh!

jakobbotschJun 6, 2024

Choose a reason for hiding this comment

Uh oh!

jakobbotsch commented Jun 6, 2024

Uh oh!

tannergooding commented Jun 6, 2024

Uh oh!

tannergooding commented Jun 6, 2024

Uh oh!

jakobbotsch commented Jun 6, 2024

Uh oh!

jakobbotsch commented Jun 6, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

jakobbotsch commented Jun 5, 2024

Uh oh!

dotnet-policy-serviceBot commented Jun 5, 2024

Uh oh!

jakobbotschJun 6, 2024

Choose a reason for hiding this comment

Uh oh!

jakobbotsch commented Jun 6, 2024

Uh oh!

tannergooding commented Jun 6, 2024

Uh oh!

tannergooding commented Jun 6, 2024

Uh oh!

jakobbotsch commented Jun 6, 2024

Uh oh!

jakobbotsch commented Jun 6, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

jakobbotsch commented Jun 5, 2024

Uh oh!

dotnet-policy-serviceBot commented Jun 5, 2024

Uh oh!

jakobbotschJun 6, 2024

Choose a reason for hiding this comment

Uh oh!

jakobbotsch commented Jun 6, 2024

Uh oh!

tannergooding commented Jun 6, 2024

Uh oh!

tannergooding commented Jun 6, 2024

Uh oh!

jakobbotsch commented Jun 6, 2024

Uh oh!

jakobbotsch commented Jun 6, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!