Improve preferencing and code generation for FMA

[CarolEidt]

As pointed out in dotnet/coreclr#25387, there are improvements to be made in the handling of the FMA intrinsics:

• Lowering should bias the containment such that the overwritten operand is a last use if possible.
• The register allocator should preference the overwritten operand.
• If all the operands are in registers, the code generator should choose the encoding based on whether the target register matches one of the input registers.

dotnet/coreclr#25387 includes a code snippet illustrating the issue.

category:cq
theme:vector-codegen
skill-level:expert
cost:large

[BruceForstall]

@CarolEidt Should this remain a 5.0 issue, or should it be moved to Future?

[CarolEidt]

This probably doesn't prioritize over the other work in progress, but I believe it is a fairly straightforward issue to fix, so perhaps it would be a good task for someone wanting to gain expertise in the backend of the JIT. But perhaps change to Future.

[BruceForstall]

I went ahead and moved it to Future, but we can always choose to bring it back.

[weilinwa]

Hi, @CarolEidt. I'm interested in this issue and would like to work on it. Could you please help me to confirm if my understanding of the requirement is correct? Thanks!

What we want to improve here is to generate the best fit FMA instruction for situations that the computation result is written into one of the three input operands. To achieve this, we need to add checks and bias containment in lowering. And also do corresponding works in LSRA and Codegen phases.

Here are the three places I'm planning to add code in:

1. Lowering: https://github.com/dotnet/runtime/blob/main/src/coreclr/jit/lowerxarch.cpp#L6303
2. LSRA: https://github.com/dotnet/runtime/blob/main/src/coreclr/jit/lsraxarch.cpp#L2339
3. Codegen: https://github.com/dotnet/runtime/blob/main/src/coreclr/jit/hwintrinsiccodegenxarch.cpp#L2135

[BruceForstall]

@kunalspathak @tannergooding

[kunalspathak]

Here are the three places I'm planning to add code in:

@weilinwa - That looks right.

[weilinwa]

Hi, @kunalspathak. Thanks for the confirmation!
I have one follow up question about what is the classical method to check whether one of the operand is overwritten. I was able to do this by checking if one of the operand's lclNum (GetLclNum()) equals to this value of the next node(node->gtNext). Is there a more decent way to get the variable that the result is written into instead of getting the next node?

[tannergooding]

We also have #12212 and #11260 as related issues.

IIRC, most of these issues were root caused to #6358. That is, to allow the register allocator to set multiple operands as "optional" for the cases where the instruction is either commutative (e.g. Add, Multiply, etc) or where it has multiple forms (e.g. FusedMultiplyAdd).

There are several notes in both of the related issues that provide some additional analysis into the issue and potential avenues for fixing it.

[kunalspathak]

method to check whether one of the operand is overwritten

There might be better way to do this, but one of the method that I can think of is NodesAreEquivalentLeaves():

runtime/src/coreclr/jit/lower.cpp

Line 6257 in d4b98b9

return tree1->AsLclVarCommon()->GetLclNum() == tree2->AsLclVarCommon()->GetLclNum();