32-bit SIMD indirections don't flag use of AVX

[CarolEidt]

The LinearScan::Build methods are intended to call SetContainsAVXFlags for any potential use of AVX registers. However, this is not done in LinearScan::BuildIndir(), which can encounter loads or stores of 32-bit SIMD types (and note that the general case in LinearScan::BuildNode(), which calls this method for any tree for which varTypeIsFloatingis true, doesn't cover this case because that only coversTYP_FLOATandTYP_DOUBLE`).

[CarolEidt]

I'm working on a fix for this. There are lots of diffs. Here's an example of a small method that lacked the vzeroupper before, but has it now:

G_M28540_IG01:
       vzeroupper 
       nop      

G_M28540_IG02:
       add      rcx, 8
       vmovupd  ymm0, ymmword ptr[rcx]
       vmovupd  ymmword ptr[rdx], ymm0
       mov      rax, rdx

G_M28540_IG03:
       vzeroupper 
       ret      

BEFORE:

; Total bytes of code 23, prolog size 5 for method <>f__AnonymousType0`1[Vector`1][System.Numerics.Vector`1[System.Single]]:get_message():struct:this

AFTER

; Total bytes of code 26, prolog size 5 for method <>f__AnonymousType0`1[Vector`1]
[System.Numerics.Vector`1[System.Single]]:get_message():struct:this

[CarolEidt]

cc @fiigii @tannergooding @dotnet/jit-contrib

I found this because, in working on supporting the HVA calling convention for Arm64, I found it was useful to directly represent SIMD arguments, rather than having them wrapped in OBJ nodes. This changed some block copies to direct loads/stores (reducing code size as well, since it replaced two 16-byte load/store with one 32-byte load/store). However, it also exposed some places where the vzeroupper was no longer being generated.

[fiigii]

I found this because, in working on supporting the HVA calling convention for Arm64

Don’t you mean for x64?

[CarolEidt]

Don’t you mean for x64?

No, I'm actually working on Arm64 HVA support - but the changes to the handling of SIMD nodes (not being under OBJ nodes) was not target-specific, and it uncovered this issue.

[fiigii]

@CarolEidt After consulted our native compiler experts, I think we probably can improve the VZEROUPPER codegen, please see https://github.com/dotnet/coreclr/issues/21062

[CarolEidt]

@fiigii - it would be great to improve the vzeroupper codegen, but I need to make a decision in the short term about whether to add in the vzerouppers (inserted, as today, in both prologue and epilogue), or to lose the vzerouppers in some of the cases that have them today.
So - the question is whether it is better to have both or none.

[fiigii]

or to lose the vzerouppers in some of the cases that have them today.

I do not think we can eliminate vzerouppers in the epilogue, which will impact external code calling managed code (reverse P/Invoke).