I split and categorized the hardware intrinsic tests to make it easier to tell what coverage exists for each ISA and each instruction.

A good portion of the code could be shared and it might be worth refactoring sooner rather than later.

For theCompareGreaterThan intrinsics, the hardware manual recommends using the inverse operations or by using software emulation (swapping the operands and using a different predicate).

Using the inverse operations is preferred, correct? I was trying to think of reasons why software emulation would be suggested, but came up drawing a blank....

FYI.@fiigii

I figured I would start on this while waiting for the scalar intrinsic PR to get merged. I believe you are going to be focusing on AVX/AVX2, so I hopefully am not duplicating work you've already done here 😄

@tannergooding Thank you so much for the work!

so I hopefully am not duplicating work you've already done here

My next step is to implementLoad/Store of AVX/AVX2/SSE/SSE2 because these memory-access intrinsics need a bit more infrastructure.

I recommend you start with simple intrinsics that generate single instruction (e.g., arithmetic, bit manipulation, and comparison, etc.). Then certain helper intrinsics can be expanded to combinations of these simple intrinsics.

For both this and emitIns_SIMD_R_R_R above: Do we have a work item tracking support for reg2 being a memory operand when it is properly aligned?

Yes, this feature is in my plan, we have to enable containment analysis on hardware intrinsic in the future. In C++, users can indicate this codegen by deferring pointers of vectors, but C# has no pointer to managed type. So this feature would considerably impact CQ.
BTW, not only "reg2 being a memory operand", but also reg1 to foldStore*.

but C# has no pointer to managed type

Hmm, it does have that -ref. Akabyref in JIT.

this feature is in my plan, we have to enable containment analysis on hardware intrinsic in the future

To be clear.

varres=Avx.Add(vec1,Avx.Load(address));

should generate

vaddpsymm1,ymm2,[adress]

To be clear...

Yes. Though I suppose it should also work withAvx.Add(vec1, *p) wherep is a pointer of appropriate vector type. In fact it's not clear ifLoad is actually needed. OnlyLoadAligned is obviously needed because there's no way to encode the fact that the pointer is properly aligned in IL.

Hmm, it does have that - ref. Aka byref in JIT.

But that requires overloading intrinsics withref and allow convertingref element to/fromref Vector128/256<T>.

But that requires overloading intrinsics with ref and allow converting ref element to/from ref Vector128/256.

Only the load/store intrinsics would need that. I think that was discussed but I don't remember how exactly we ended up only with pointer versions. Anyway, doesn't matter to much, they can be added if deemed useful at some point.

Only the load/store intrinsics would need that.

I meant C++ can compile:

// vec1 is a __m256 and addr is float*auto a = _mm256_add_ps(vec1, *(__m256*)addr);

to

vaddpsymm0,ymm0, ymmword ptr[addr]

But, in C#, we have to rely on foldingLoad into the comsuer intrinsics.

Only LoadAligned is obviously needed because there's no way to encode the fact that the pointer is properly aligned in IL.

Most of the aligned and unaligned instructions have no difference of performance and function on modern Intel CPUs when the load/store fall into one cache-line. Users should be responsible for alignment of pointers.

I meant C++ can compile:

Yes, and similar code will work in C# except that you can't generateaddps xmm0, xmmword ptr [addr] because SSE2 requires memory operands to be aligned and the JIT has no way to know if addr is 16 byte aligned or not.

But, in C#, we have to rely on folding Load into the comsuer intrinsics.

For SSE2, yes.Sse2.Add(v1, Sse2.LoadAligned(addr)) should generateaddps xmm0, xmmword ptr[addr].

you can't generate addps xmm0, xmmword ptr [addr] because SSE2 requires memory operands to be aligned and the JIT has no way to know if addr is 16 byte aligned or not.

Sse2.Add(v1, Sse2.LoadAligned(addr)) should generate addps xmm0, xmmword ptr[addr].

@mikednaddps does not require 16-byte alignment. OnlyType 1 instructions require explicit alignment:

@fiigii, there are some instructions, like addsubpd, where they explicitly indicate (on the actual instruction page) that the source operand must be aligned or #GP will be generated.

It would be useful to determine which section of the manual is accurate.

Hmm, too lazy to dig through the docs at this hour. Let's test:

__m128 a[42];__asm addps xmm0, xmmword ptr [a+1]

Crashes with "read access violation". Runs fine with[a] or[a+16].
But:

__m128 a[42];__asm vaddps xmm0, xmm0, xmmword ptr [a+1]

Runs fine.

So yes, classic SSE2 (no VEX encoded) instructions require 16 byte alignment.

@mikedn@tannergooding Sorry, I was worry.Type 2 instructions also require alignment withlegacy SSE encoding

In summary, we should foldLoad/Store for all VEX-encoding instructions.
BTW,@mikedn could you point any code that I can learn enabling containment analysis for SIMD operations? I am not very familiar with this part.

could you point any code that I can learn enabling containment analysis for SIMD operations

See the variousContainCheckX functions in lowerxarch.cpp. There'sContainCheckSIMD but it's rather limited in what it does. SeeContainCheckBinary too.

In short:

• If the second operand is a memory operand (GT_IND usually) you can make it contained by callingMakeSrcContained.
• If the second operand is a local variable then you may callSetRegOptional to tell the register allocator that it does not need to load the variable into a register (if it's not already in a register).
• If the first operand is a memory operand/local variable and the instruction is commutative then you could try to swap the operands to take advantage of containment
• AFAIR there aren't many, if any, SSE/AVX instruction that have a RMW (read/modify/write) form (e.g. noaddps xmmword ptr [mem], xmm0). That will simplify things as handling this form is rather convoluted.

Note: CI results are inaccurate untilhttps://github.com/dotnet/coreclr/issues/15618 is resolved as theIsSupported check is returning false and no intrinsics actually have code being generated.

I am testing locally to ensure Windows x64 is working, but that is all the validation I am doing at this time.

@fiigii,@mikedn.

ImplementedSSE_Shuffle usingGT_LIST for the operands. It's fairly straightforward and can be fairly well isolated from the other code paths.

@tannergooding I will change the importer and codgen of HW intrinsic to a table-driven implementation, so that@mikedn's solution ("add a integer data member to GenTreeHWIntrinsic and store the immediate in it.") may be better to unify the exception code.

ImplementedSet,SetAll, andSetZero intrinsics.

All that's left now isLoad,Store, andStaticCast (and improving codegen in general).

Had to resolve a merge conflict with the System.Math.Round intrinsic PR (#14736).

Went ahead and added the function header comments and changedisNumericType to bevarTypeIsArithmetic instead.

Will merge once tests are green.

Do not want to bother you, but frankejit is broken again:
f:\codegenmirror\src\ndp\clr\src\jit\emitxarch.cpp(4140): error C3861: 'emitHandleMemOp': identifier not found [F:\CodegenMirror\src\NDP\clr\src\jit\frankenjit\frankenjit.nativeproj]

So new functions should be under#ifndef LEGACY_BACKEND

Do not want to bother you, but frankejit is broken again:

No worries. I should have remembered I needed toifdef the R_R_A_I method after just fixing the others.

Fix should be#15900. I tested locally on the TFS sources and it looks like JIT builds succesfully.