Improve Bmi2.MultiplyNoFlags codegen

[pentp]

I went with the magic load route in lowering. It works out quite well (codegen is ideal, if a local var is used for the low result). Fixes #21899.

@mikedn, @fiigii, @CarolEidt do you think this might be acceptable, as all changes are limited to BMI specific functions?

[fiigii]

All the MultiplyNoFlags tests failed. Could you please address them at first?

[pentp]

@dotnet-bot test Windows_NT x64 min_opt ryujit CoreCLR Perf Tests Correctness

[pentp]

@dotnet-bot test Windows_NT x86 full_opt ryujit CoreCLR Perf Tests Correctness

[pentp]

@dotnet-bot test Windows_NT x86 full_opt ryujit CoreCLR Perf Tests Correctness

[pentp]

Fixed a problem with tier0, this is ready for review now.

[pentp]

@fiigii could you take a look at this?

[fiigii]

I will take a look tonight.
@mikedn @CarolEidt PTAL

[mikedn]

I'd wait for @CarolEidt's feedback before going further with this. The "magic" way wasn't exactly the favored approach.

[tannergooding]

It's likely also worth keeping in mind that there are other APIs (such as Math.DivRem) that would possibly benefit from whatever optimization we decide to do here (whether it is something like this as an interim solution, or something that isn't so "magic" as a more permanent solution).

[pentp]

I explored the MultiRegOp path used in 32-bit mode also, but that looked more complicated and most importantly, would not be pay-for-play as this magic load solution.

[pentp]

@CarolEidt could you take a look at this? I know this solution feels like a hack, but at least it's pretty contained and I'd like to use MULX in decimal math, but in its current form it's not really usable because of the memory accesses.

[CarolEidt]

I'm still not keen on this approach, though it is cleaner than I feared.
It will take me some time to get to this, but the review would go faster if there were more detailed comments about what's being done at each stage (and they will be needed if/when this is merged in any case). So if you could add some comments that would be great. Thanks!

[maryamariyan]

Thank you for your contribution. As announced in dotnet/coreclr#27549 this repository will be moving to dotnet/runtime on November 13. If you would like to continue working on this PR after this date, the easiest way to move the change to dotnet/runtime is:

1. In your coreclr repository clone, create patch by running git format-patch origin
2. In your runtime repository clone, apply the patch by running git apply --directory src/coreclr <path to the patch created in step 1>

[BruceForstall]

Given the lack of activity in this PR, I'm going to close it. Feel free to re-open if work resumes. Note that the repo will move soon, so it would be best to wait until the new repo opens to create a new PR.