JIT: DNER multiregs with SIMD12s

[jakobbotsch]

Locals with SIMD12 fields will span multiple registers when they end up as multireg returns, so these should always be DNER'd.

Fix #91214

[ghost]

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

Issue Details

---

Locals with SIMD12 fields will never match the ABI when they end up as multireg returns, so these should always be DNER'd.

Fix #91214

Author:	jakobbotsch
Assignees:	-
Labels:	area-CodeGen-coreclr
Milestone:	-

[jakobbotsch]

cc @dotnet/jit-contrib PTAL @EgorBo

No diffs (except large TP diffs, see #91563 (comment))

[EgorBo]

hm... I thought that the fix is more complicated per our discussion in discord with you and @SingleAccretion :

that's why I closed mine that touches the same path

[jakobbotsch]

hm... I thought that the fix is more complicated per our discussion in discord with you and @SingleAccretion :

that's why I closed mine that touches the same path

After thinking about it some more (and checking diffs) I don't think we need anything more complicated here. I believe that all cases where we call CheckMultiRegLclVar that involves SIMD12 in the source or destination is going to end up with some kind of mismatch that the backend cannot handle; this includes the call and return cases (where the return/call has it spread out over two GPR registers, and the LCL always has it in a SIMD register) and the HWI case (where it will be split or condensed in multiple SIMD registers). I do not think that CheckMultiRegLclVar is used for LCL_VAR <-> LCL_VAR compatibility checks (these should already have been DNER'd earlier, or block morphing should have rewritten them). Maybe @SingleAccretion disagrees?

It might still be nice to do the ReturnTypeDesc thing, which is more general and obviously correct logic, but it's also a much larger refactoring so probably not something we'd want to do for 8.0.

[SingleAccretion]

Maybe @SingleAccretion disagrees?

The change looks good to me. Though I it would be nice to "formally prove" mismatches can only arise from SIMD12 on local side, I agree it is convincing that it is indeed the case.

LCL_VAR <-> LCL_VAR

One will never see this for multi-reg locals, due to (as you said) block morphing.

[jakobbotsch]

Failures are #91705 and #91723

[jakobbotsch]

/backport to release/8.0

[github-actions]

Started backporting to release/8.0: https://github.com/dotnet/runtime/actions/runs/6145265483

[github-actions]

@jakobbotsch backporting to release/8.0 failed, the patch most likely resulted in conflicts:

$ git am --3way --ignore-whitespace --keep-non-patch changes.patch

Applying: JIT: DNER multiregs with SIMD12s
Using index info to reconstruct a base tree...
M	src/coreclr/jit/lower.cpp
A	src/tests/JIT/Regression/JitBlue/Runtime_91174/Runtime_91174.cs
A	src/tests/JIT/Regression/JitBlue/Runtime_91335/Runtime_91335.cs
Falling back to patching base and 3-way merge...
CONFLICT (modify/delete): src/tests/JIT/Regression/JitBlue/Runtime_91335/Runtime_91335.cs deleted in HEAD and modified in JIT: DNER multiregs with SIMD12s. Version JIT: DNER multiregs with SIMD12s of src/tests/JIT/Regression/JitBlue/Runtime_91335/Runtime_91335.cs left in tree.
CONFLICT (modify/delete): src/tests/JIT/Regression/JitBlue/Runtime_91174/Runtime_91174.cs deleted in HEAD and modified in JIT: DNER multiregs with SIMD12s. Version JIT: DNER multiregs with SIMD12s of src/tests/JIT/Regression/JitBlue/Runtime_91174/Runtime_91174.cs left in tree.
Auto-merging src/coreclr/jit/lower.cpp
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 JIT: DNER multiregs with SIMD12s
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
Error: The process '/usr/bin/git' failed with exit code 128

Please backport manually!

[github-actions]

@jakobbotsch an error occurred while backporting to release/8.0, please check the run log for details!

Error: git am failed, most likely due to a merge conflict.