Fix HFA/HVA classification

[CarolEidt]

Fix #35144 and #35976

[sandreenko]

Jit/ToolBox changes look good, with one question about compFloatingPointUsed.
I like how clean it looks with DOUBLE\Vector64 separation.

[sandreenko]

is it safe to drop compFloatingPointUsed = true;?

[CarolEidt]

No, that was a mistake

[CarolEidt]

@davidwrighton - the crossgen2 tests are failing in CI, but passing on my local system. Can you advise me what I might be missing?

[CarolEidt]

@dotnet/dnceng - is this a known issue? I see it on two of my PRs, and at least one other as well:

##[error].packages/microsoft.dotnet.arcade.sdk/5.0.0-beta.20280.1/tools/RepositoryValidation.proj(33,5): error : (NETCORE_ENGINEERING_TELEMETRY=Build) License file content '/Users/runner/runners/2.169.1/work/1/s/LICENSE.TXT' doesn't match the expected license '/Users/runner/runners/2.169.1/work/1/s/.packages/microsoft.dotnet.arcade.sdk/5.0.0-beta.20280.1/tools/Licenses/MIT.txt'.

[premun]

@CarolEidt looks like folks are aware and fixed it already here: #37626

Rebase should get you going. Meanwhile we are looking into improving the process so that this doesn't happen again.

[CarolEidt]

@jkoritzinsky @davidwrighton @sandreenko PTAL
@dotnet/jit-contrib

[sandreenko]

Jit/ToolBox changes LGTM.

[CarolEidt]

ping @jkoritzinsky @davidwrighton
perhaps @jkotas could review?

[tannergooding]

There aren't any architectures that have HVA for Vector256?

[tannergooding]

Looks like __vectorcall for x64 will eventually fit this bill: https://godbolt.org/z/DMX7Y2, but not for ARM32/ARM64 (which don't support Vector256<T>) nor the default calling conventions for x86 or x64 on Unix/Windows.

System V does treat a simple wrapper over __m256 as if it was directly __m256 however, not sure if that is classified as an HFA/HVA by the JIT...

[CarolEidt]

Currently the runtime (JIT + VM) handles the System V ABI completely separately. HFA/HVA is ARM32/ARM64 only.

[tannergooding]

The changes make sense to me. I imagine the same code paths would need to be updated when Half support is added to the vector types?

[AntonLapounov]

Technically VECTOR64 and VECTOR128 are HVAs, not HFAs. For that reason I have renamed HFA to either HA or HomogenousAggregate everywhere in managed code. If we introduce and expose a new enumeration, I would prefer to name it correctly from the beginning. However, I realize there are lots of hfa usage in JIT code, so leaving it up to you.

[CarolEidt]

The changes make sense to me. I imagine the same code paths would need to be updated when Half support is added to the vector types?

I confess that I haven't looked at the ABI requirements for Half, but I'm not sure why they would require a change, as (at least for now) the classification for vectors is independent of the element type.

[jkoritzinsky]

VM interop code LGTM

[davidwrighton]

As far as the change to the product goes, it looks ok, although sufficiently complex that I don't have complete confidence that I can review it to complete correctness. So I've made some suggestions of making the test more complex in ways that will cause our various automated runs to find bugs more effectively.

[davidwrighton]

Could you change this test to pass an object after the T parameter? I would like it for GC Stress to cover the case where we use the calling convention processing logic of the VM to parse all of this.

[davidwrighton]

In particular make the function be written as:

static void Foo<T>(T x, object o)
{
    if (o.GetType() != typeof(string)) throw new Exception();
    if (((string)o) != "SomeString") throw new Exception();
}

and call it passing a string "SomeString" as the extra parameter.

[davidwrighton]

Also, if you could mark the Foo method as AggressiveOptimization so that it isn't compiled by crossgen that will also help chase down the case where crossgen compiles this different from what the normal runtime does.

[CarolEidt]

@davidwrighton - Thanks for the review, and for the suggestions for improving the test!