JIT: Remove LclVarDsc::lvExactSize and LclVarDsc::lvSIMDType

[jakobbotsch]

Turn these into functions.

LclVarDsc shrinks by 8 bytes on win-x64, diff of layout: https://www.diffchecker.com/YcUPNTpu

[ghost]

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

Issue Details

---

Turn these into functions.

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

[jakobbotsch]

Diffs look to be because we were forgetting to set lvSIMDType = 1 for this particular local:

runtime/src/coreclr/jit/simd.cpp

Line 120 in 5265218

lvaSIMDInitTempVarNum = lvaGrabTempWithImplicitUse(falseDEBUGARG("SIMDInitTempVar"));

That means it wasn't being aligned in the stack frame before.

[jakobbotsch]

Diffs. As mentioned above, diffs are due to some more alignment for some SIMD locals. It is also a slight TP regression (0.02% to 0.05% in minopts, 0.08% to 0.10% in FullOpts) to remove this since calling lvExactSize is more expensive. I think the trade off is worth it -- we drop 8 bytes from every LclVarDsc and we don't keep a redundant field around that needs to be kept up to date (in both #83036 and #83306 I had failures from forgetting to set this field for SIMD types).

cc @dotnet/jit-contrib

[EgorBo]

LGTM, LclVarDsc is fairly sensitive to changes, e.g. I locally re-shuffled some fields in it and got -0.25% TP improvement while keeping size the same, will file a PR to cover TP regressions you hit

[jakobbotsch]

cover TP regressions you hit

I think we can just ignore these kinds of TP regressions, that's what we've done previously. If the native compiler decides that it is more efficient to emit shifts/adds instead of imul, then we should trust in it. It just further shows that the methodology of counting instructions executed is not a silver bullet (not that we thought that before).

Edit: Ah, I just realized you probably meant the actual TP regressions from calling lvExactSize() ... :-)