Ensure partial Vector256 acceleration is still possible on AVX only hardware

[tannergooding]

This is a continuation of #72522. CC. @EgorBo, @saucecontrol

Since Vector256 first previewed in .NET Core 2.1, we've had partial acceleration of the members exposed by Vector256 on AVX only hardware such that customers expect that acceleration to be present for some of the API surface.

However, in .NET 7 this was regressed due to the introduction of the other xplat helper APIs that cover a broader range of functionality and it negatively impacts devs who were targeting AVX only hardware such as IvyBridge and SandyBridge.

This adjusts the tracking so that all APIs, except Equals, which had AVX only hardware acceleration support in .NET 6 continue having such acceleration in .NET 7. It additionally lights up a select few instructions which are trivially handled on AVX only hardware for all supported types. -- Equals is not directly accelerated because it had a compat break in .NET 7 so that it met the .NET IEquatable<T> implementation requirements related to GetHashCode, meaning that float/double require specialized handling for NaN.

This does not accelerate other APIs, such as op_Addition, which require AVX2 for certain types (generally integral types). For these new APIs, devs should check Vector256.IsHardwareAccelerated instead.

[ghost]

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

Issue Details

---

This is a continuation of #72522. CC. @EgorBo, @saucecontrol

Since Vector256 first previewed in .NET Core 2.1, we've had partial acceleration of the members exposed by Vector256 on AVX only hardware such that customers expect that acceleration to be present for some of the API surface.

However, in .NET 7 this was regressed due to the introduction of the other xplat helper APIs that cover a broader range of functionality and it negatively impacts devs who were targeting AVX only hardware such as IvyBridge and SandyBridge.

This adjusts the tracking so that all APIs, except Equals, which had AVX only hardware acceleration support in .NET 6 continue having such acceleration in .NET 7. It additionally lights up a select few instructions which are trivially handled on AVX only hardware for all supported types. -- Equals is not directly accelerated because it had a compat break in .NET 7 so that it met the .NET IEquatable<T> implementation requirements related to GetHashCode, meaning that float/double require specialized handling for NaN.

This does not accelerate other APIs, such as op_Addition, which require AVX2 for certain types (generally integral types). For these new APIs, devs should check Vector256.IsHardwareAccelerated instead.

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

[tannergooding]

/azp run runtime-coreclr jitstress-isas-x86

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[tannergooding]

This needs local testing on an AVX only machine before being merged. We have a small subset of AVX only machines in our MacOS test pool but getting such a machine is non-deterministic.

I have an AVX only laptop I plan on running the tests against to help validate everything is working as expected.

[tannergooding]

As and the other As* APIs are treated as no-ops in import and fully elided.

[tannergooding]

AndNot, BitwiseAnd, BitwiseOr, ExclusiveOr, OnesComplement, and the corresponding op_* are bitwise operations and the type doesn't matter. They all have fallback paths in gtNewSimd* that treat it as TYP_FLOAT if AVX2 is not supported.

[tannergooding]

ConditionalSelect has a fallback in lowering that treats it as a & ~b over TYP_FLOAT if AVX2 isn't supported.

[tannergooding]

Ceiling and Floor are only exposed for float/double which is supported on AVX only.

[tannergooding]

ConvertToInt32 is only for float which is AVX only.

[tannergooding]

ConvertToSingle is only for int which is AVX only.

[tannergooding]

Create was already handled by @EgorBo's last PR
CreateScalarUnsafe follows the same path as Create

[tannergooding]

get_AllBitsSet and get_Zero are just specialized versions of Create

get_Count returns a constant TYP_INT in import

[tannergooding]

GetElement is either GetLower().GetElement() or GetUpper().GetElement() both of which operate on Vector128 and require SSE4.1

GetLower is a "no-op" where possible and only generates a register to register movups otherwise, which is AVX only. In the case imm is not a constant, we generate a spill and then load from memory.

[tannergooding]

Load APIs and only generate mova* or movu* both of which are supported for any type.

LoadAlignedNonTemporal probably shouldn't be marked, its AVX2 only (but we have the relevant check to exit in import)

[tannergooding]

Sqrt is float/double only, other types exit in import.

[tannergooding]

Store APIs only generate mova*, movu*, or movnt* all of which are supported for any type in AVX.

[tannergooding]

ToScalar will generate GetLower().ToScalar() which is Vector128

[JulieLeeMSFT]

@tannergooding, is this PR for .NET 7 or 8?

[tannergooding]

.NET 7, as indicated in the top post this is covering a user reported perf regression from the .NET 6 experience

[tannergooding]

jitstress-isas-x86 failures are unrelated. They are:

• GC\\API\\Frozen\\Frozen\\Frozen.cmd
• JIT\\Regression\\JitBlue\\GitHub_27924\\GitHub_27924\\GitHub_27924.cmd
• CoreMangLib\\system\\span\\RefStructWithSpan\\RefStructWithSpan.cmd
• GC/Scenarios/FinalizeTimeout/FinalizeTimeout/FinalizeTimeout.sh

Seems to all be:

• Assert: slot_table[slot_index] == nullptr #73692: Assert failure(PID 35619 [0x00008b23], Thread: 357724 [0x5755c]): slot_table[slot_index] == nullptr
• Assert (g_gc_lowest_address <= address) && (address < g_gc_highest_address) File: /__w/1/s/src/coreclr/gc/gc.cpp Line: 3571 #73653: Assert failure(PID 20734 [0x000050fe], Thread: 20734 [0x50fe]): (g_gc_lowest_address <= address) && (address < g_gc_highest_address)

[JulieLeeMSFT]

@BruceForstall @EgorBo Please code review with a high priority by tomorrow because @tannergooding wants to merge this for .NET 7.

[tannergooding]

I'll have confirmation of running this on an i5-3317U (Ivy Bridge which has AVX but no AVX2) in an hour or two.

[tannergooding]

Validated everything passes on my i5-3317U on Ubuntu 22.04 x64.

Got confirmation from @saucecontrol over Discord on similar results for Windows on their machine.

So this should be good for merging once it gets sign-off.

[saucecontrol]

Can confirm I've run CLR and libs tests on a Sandy Bridge Windows Server (Xeon E3-1230). No related failures.

[EgorBo]

Looks good to me assuming CI failures are unrelated and it works on an SB cpu,
the only thing - HW_Flag_AvxOnlyCompatible slightly confuses me, you marked several instructions with it and it looks like it's saying that e.g. "AndNot" is not available if AVX2 is presented - do I read it wrong?

[saucecontrol]

That's AvxOnly as in "works even if only AVX is available".

[EgorBo]

That's AvxOnly as in "works even if only AVX is available".

Ah, I see, LGTM then

[tannergooding]

Looks good to me assuming CI failures are unrelated and it works on an SB cpu,

Yep. CI failures were all checked above (#73720 (comment)). It was tested on an IB (me) and SB (saucecontrol).

[kunalspathak]

Might be improvements in dotnet/perf-autofiling-issues#7326