JIT: Added SVE APIs `CreateMaskForFirstActiveElement` and `CreateMaskForNextActiveElement` #104002

TIHan · 2024-06-25T23:20:38Z

Contributes to #99957

Adds:

CreateMaskForFirstActiveElement
CreateMaskForNextActiveElement

…ctiveElement

…nstead of mov.

dotnet-issue-labeler · 2024-06-25T23:20:44Z

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

dotnet-issue-labeler · 2024-06-25T23:20:45Z

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

dotnet-policy-service · 2024-06-25T23:21:14Z

Tagging subscribers to this area: @dotnet/area-system-runtime-intrinsics
See info in area-owners.md if you want to be subscribed.

TIHan · 2024-06-25T23:29:16Z

test_results.txt

@dotnet/arm64-contrib @kunalspathak this is ready. Current test failures are only in UnsafeRead and I believe it is due to the predicate callee-save register bug.

Example assembly of one of the failures:

G_M52469_IG41:  ;; offset=0x00C0
            ptrue   p0.h
                                                ;; size=4 bbWeight=0.25 PerfScore 0.50
G_M52469_IG42:  ;; offset=0x00C4
            cmpne   p0.h, p0/z, z16.h, #0
                                                ;; size=4 bbWeight=0.25 PerfScore 0.75
G_M52469_IG43:  ;; offset=0x00C8
            mov     x0, x22
                                                ;; size=4 bbWeight=0.25 PerfScore 0.12
G_M52469_IG44:  ;; offset=0x00CC
            movz    x1, #0x7DB0      // code for JIT.HardwareIntrinsics.Arm._Sve.SimpleBinaryOpTest__Sve_CreateMaskForFirstActiveElement_ushort+DataTable:get_inArray2Ptr():ulong:this
                                                ;; size=4 bbWeight=0.25 PerfScore 0.12
G_M52469_IG45:  ;; offset=0x00D0
            movk    x1, #0xE8D0 LSL #16
                                                ;; size=4 bbWeight=0.25 PerfScore 0.12
G_M52469_IG46:  ;; offset=0x00D4
            movk    x1, #0x7FFC LSL #32
                                                ;; size=4 bbWeight=0.25 PerfScore 0.12
G_M52469_IG47:  ;; offset=0x00D8
            ldr     x1, [x1]
                                                ;; size=4 bbWeight=0.25 PerfScore 0.75
G_M52469_IG48:  ;; offset=0x00DC
            blr     x1
                                                ;; size=4 bbWeight=0.25 PerfScore 0.25
G_M52469_IG49:  ;; offset=0x00E0
            ldr     q16, [x0]
                                                ;; size=4 bbWeight=0.25 PerfScore 0.75
G_M52469_IG50:  ;; offset=0x00E4
            ptrue   p1.h
                                                ;; size=4 bbWeight=0.25 PerfScore 0.50
G_M52469_IG51:  ;; offset=0x00E8
            cmpne   p1.h, p1/z, z16.h, #0
                                                ;; size=4 bbWeight=0.25 PerfScore 0.75
G_M52469_IG52:  ;; offset=0x00EC
            pfirst  p1.b, p0, p1.b
                                                ;; size=4 bbWeight=0.25 PerfScore 0.50

tannergooding · 2024-06-26T04:29:38Z

I believe it is due to the predicate callee-save register bug.

I don't believe the general callee save/trash support is hooked up at the moment and it's instead something @kunalspathak is working on enabling.

a74nh · 2024-06-26T06:13:49Z

src/coreclr/jit/hwintrinsiccodegenarm64.cpp

+                break;
+            }
+
+            case NI_Sve_CreateMaskForNextActiveElement:


For this one can you remove HW_Flag_SpecialCodeGen and then everything here will be done by common code?

It uses INS_sve_mov. I could expand emitIns_Mov to handle it though.

Is it possible to update the existing isRMW code to handle these intrinsics? It takes care of mov as well.

Even if we cannot do it, the body of each case is idential and should be shared.

It can, but would need to update emitIns_Mov to be aware of predicate registers and use INS_sve_mov for them.

without SpecialCodeGen flag, where in the current code do we go, where we call emitIns_Mov()?

kunalspathak · 2024-06-26T16:28:33Z

src/coreclr/jit/hwintrinsiclistarm64sve.h

@@ -47,6 +47,8 @@ HARDWARE_INTRINSIC(Sve,           CreateFalseMaskSingle,
 HARDWARE_INTRINSIC(Sve,           CreateFalseMaskUInt16,                                            -1,      0,      false, {INS_invalid,        INS_invalid,        INS_invalid,        INS_sve_pfalse,     INS_invalid,        INS_invalid,        INS_invalid,        INS_invalid,        INS_invalid,        INS_invalid},     HW_Category_SIMD,                  HW_Flag_Scalable|HW_Flag_ReturnsPerElementMask)
 HARDWARE_INTRINSIC(Sve,           CreateFalseMaskUInt32,                                            -1,      0,      false, {INS_invalid,        INS_invalid,        INS_invalid,        INS_invalid,        INS_invalid,        INS_sve_pfalse,     INS_invalid,        INS_invalid,        INS_invalid,        INS_invalid},     HW_Category_SIMD,                  HW_Flag_Scalable|HW_Flag_ReturnsPerElementMask)
 HARDWARE_INTRINSIC(Sve,           CreateFalseMaskUInt64,                                            -1,      0,      false, {INS_invalid,        INS_invalid,        INS_invalid,        INS_invalid,        INS_invalid,        INS_invalid,        INS_invalid,        INS_sve_pfalse,     INS_invalid,        INS_invalid},     HW_Category_SIMD,                  HW_Flag_Scalable|HW_Flag_ReturnsPerElementMask)
+HARDWARE_INTRINSIC(Sve,           CreateMaskForFirstActiveElement,                                  -1,      2,      true,  {INS_sve_pfirst,     INS_sve_pfirst,     INS_sve_pfirst,     INS_sve_pfirst,     INS_sve_pfirst,     INS_sve_pfirst,     INS_sve_pfirst,     INS_sve_pfirst,     INS_invalid,        INS_invalid},     HW_Category_SIMD,                  HW_Flag_Scalable|HW_Flag_ExplicitMaskedOperation|HW_Flag_LowMaskedOperation|HW_Flag_ReturnsPerElementMask|HW_Flag_LowMaskedOperation|HW_Flag_SpecialCodeGen|HW_Flag_HasRMWSemantics)


This doesn't need HW_Flag_LowMaskedOperation for pfirst.

kunalspathak · 2024-06-26T16:32:16Z

src/coreclr/jit/hwintrinsiclistarm64sve.h

@@ -47,6 +47,8 @@ HARDWARE_INTRINSIC(Sve,           CreateFalseMaskSingle,
 HARDWARE_INTRINSIC(Sve,           CreateFalseMaskUInt16,                                            -1,      0,      false, {INS_invalid,        INS_invalid,        INS_invalid,        INS_sve_pfalse,     INS_invalid,        INS_invalid,        INS_invalid,        INS_invalid,        INS_invalid,        INS_invalid},     HW_Category_SIMD,                  HW_Flag_Scalable|HW_Flag_ReturnsPerElementMask)
 HARDWARE_INTRINSIC(Sve,           CreateFalseMaskUInt32,                                            -1,      0,      false, {INS_invalid,        INS_invalid,        INS_invalid,        INS_invalid,        INS_invalid,        INS_sve_pfalse,     INS_invalid,        INS_invalid,        INS_invalid,        INS_invalid},     HW_Category_SIMD,                  HW_Flag_Scalable|HW_Flag_ReturnsPerElementMask)
 HARDWARE_INTRINSIC(Sve,           CreateFalseMaskUInt64,                                            -1,      0,      false, {INS_invalid,        INS_invalid,        INS_invalid,        INS_invalid,        INS_invalid,        INS_invalid,        INS_invalid,        INS_sve_pfalse,     INS_invalid,        INS_invalid},     HW_Category_SIMD,                  HW_Flag_Scalable|HW_Flag_ReturnsPerElementMask)
+HARDWARE_INTRINSIC(Sve,           CreateMaskForFirstActiveElement,                                  -1,      2,      true,  {INS_sve_pfirst,     INS_sve_pfirst,     INS_sve_pfirst,     INS_sve_pfirst,     INS_sve_pfirst,     INS_sve_pfirst,     INS_sve_pfirst,     INS_sve_pfirst,     INS_invalid,        INS_invalid},     HW_Category_SIMD,                  HW_Flag_Scalable|HW_Flag_ExplicitMaskedOperation|HW_Flag_LowMaskedOperation|HW_Flag_ReturnsPerElementMask|HW_Flag_LowMaskedOperation|HW_Flag_SpecialCodeGen|HW_Flag_HasRMWSemantics)
+HARDWARE_INTRINSIC(Sve,           CreateMaskForNextActiveElement,                                   -1,      2,      true,  {INS_invalid,        INS_sve_pnext,      INS_invalid,        INS_sve_pnext,      INS_invalid,        INS_sve_pnext,      INS_invalid,        INS_sve_pnext,      INS_invalid,        INS_invalid},     HW_Category_SIMD,                  HW_Flag_Scalable|HW_Flag_ExplicitMaskedOperation|HW_Flag_LowMaskedOperation|HW_Flag_ReturnsPerElementMask|HW_Flag_LowMaskedOperation|HW_Flag_SpecialCodeGen|HW_Flag_HasRMWSemantics)


kunalspathak · 2024-06-26T16:34:59Z

src/coreclr/jit/hwintrinsiccodegenarm64.cpp

+                break;
+            }
+
+            case NI_Sve_CreateMaskForNextActiveElement:


Even if we cannot do it, the body of each case is idential and should be shared.

kunalspathak · 2024-06-26T16:41:47Z

src/coreclr/jit/hwintrinsiccodegenarm64.cpp

+                break;
+            }
+
+            case NI_Sve_CreateMaskForNextActiveElement:


without SpecialCodeGen flag, where in the current code do we go, where we call emitIns_Mov()?

kunalspathak · 2024-06-26T16:46:21Z

src/tests/JIT/HardwareIntrinsics/Arm/Shared/Helpers.cs

@@ -28,6 +28,346 @@ public static Vector<T> InitVector<T>(Func<int, T> f)
            return new Vector<T>(arr);
        }

+        public static byte[] CreateMaskForFirstActiveElement(byte[] mask, byte[] srcMask)


why this can't be simple as:

public static byte[] CreateMaskForFirstActiveElement(byte[] mask, byte[] srcMask) { for (var i = 0; i < count; i++) { // For active lane, set the element if (mask[i] != 0) { srcMask[i] = 1; break; } } return srcMask; }

Also, wondering if we can templatize it?

We might be able to; but would need to do some reflection to dynamically handle zero and one for the primitives.

It'll get templatized when this all gets copied back into helpers.tt

I am ok to not do templatize version if it is too complicated. We already have lot of helpers that do not use template version.

kunalspathak · 2024-06-26T16:59:00Z

src/tests/JIT/HardwareIntrinsics/Arm/Shared/Helpers.cs

+            return -1;
+        }
+
+        public static byte[] CreateMaskForNextActiveElement(byte[] mask, byte[] srcMask)


This might be easier to undersand:

public static ushort[] CreateMaskForNextActiveElement(ushort[] mask, ushort[] srcMask) { int activeElement = 0; int i; // Find the active element in srcMask for (i = 0; i < count; i++) { if (srcMask[i] == 0) { activeElement = i + 1; break; } } // Find the next active element in mask var result = new byte[Vector<ushort>.Count]; for (i = activeElement; i < count; i++) { if (mask[i] == 1) { result[i] = 1; break; } } return result; }

I was pretty much verbatim copying the logic from the arm docs.

This might be easier to undersand:

Looks good to me (ditto for the simpler CreateMaskForFirstActiveElement)

The suggestion for CreateMaskForFirstActiveElement mutates the srcMask which we do not want to do. I'll cleanup these methods though.

The suggestion for CreateMaskForFirstActiveElement mutates the srcMask which we do not want to do

does it matter for our testing?

We explicitly do the same for xarch intrinsics for the same reason, a lot of the logic for these intrinsics is quite complex and we don't want to introduce risk by trying to do any cleanup as compared to what is actually documented to occur (as that can lead to subtle bugs that are difficult to track down).

It does. I expect these helpers to not mutate any inputs.

The arm architecture manuals describe a behavior using pseudo-code already and so matching that as closely as possible in the test validation is general goodness and far more beneficial in practice than trying to make rewrite the validation APIs to some form of more aesthetically pleasing code.

That should be the intent, but simplifying the code really helps in understanding if we are even validating the right thing. It took me a while to understand the logic here. Plus, when we say "copying the logic", we are implementing it ourselves anyway, and that can have bugs as well.

but simplifying the code really helps in understanding if we are even validating the right thing

There's not really a need to understand what it's doing, the algorithm matches what is spec'd and that is sufficient for knowing its testing the right thing.

we are implementing it ourselves anyway, and that can have bugs as well.

Yes, and it is easier to validate that it is correct and matches the expected behavior when it is 1-to-1 (or as close to possible) with the architecture manual.

If we have to simplify the code, then every person needs to read the Architecture manual and work through the logic of simplifying it and understanding what the code is meant to be doing.

If we instead simply mirror the algorithm as closely as possible, it becomes far more trivial to do a comparison with the architecture manual and see that it effectively identical and therefore can be presumed correct.

Correctness is by far the most important thing here, far more than perf or any other consideration.

If there was a significant need to document a particularly complex algorithm to make it easier for reviewers to understand, that is then a separate consideration and one that can be handled instead with an attached comment (in code) that describes the operation in "simpler" terms, which then gives us something that can be trivially compared with the source of truth while still providing additional context that makes it easier to understand what's happening.

TIHan · 2024-06-26T18:03:19Z

~~@kunalspathak , if we do not use the SpecialCodeGen flag, then I have to handle emitIns_R_R_R to forward to emitIns_R_R for pnext, is that something we are willing to do?~~

It should already forward. I have an idea though how to make this work without modifying emitIns_Mov

TIHan · 2024-06-26T19:45:46Z

@dotnet/arm64-contrib @kunalspathak this is ready again.

src/coreclr/jit/hwintrinsiccodegenarm64.cpp

kunalspathak · 2024-06-27T06:13:18Z

src/coreclr/jit/hwintrinsiccodegenarm64.cpp

@@ -824,7 +824,25 @@ void CodeGen::genHWIntrinsic(GenTreeHWIntrinsic* node)
                        assert(!node->IsEmbMaskOp());
                        if (HWIntrinsicInfo::IsExplicitMaskedOperation(intrin.id))
                        {
-                            GetEmitter()->emitIns_R_R_R(ins, emitSize, targetReg, op1Reg, op2Reg, opt);
+                            if (isRMW)


can you confirm in what cases we come at this code path vs. the one at the end of this file?

CreateMaskForNextActiveElement will come there, and any table-driven HW intrinsic that has two parameters with an explicit masked operation. But CreateMaskForNextActiveElement is the first RMW to reach this path.

Why cannot NI_Sve_CreateMaskForFirstActiveElement handled here itself after you remove the SpecialCodegen flag for it. They both need INS_OPTS_SCALABLE_B as opt. So if this code can work for
NI_Sve_CreateMaskForNextActiveElement, wondering why can't it work for NI_Sve_CreateMaskForFirstActiveElement?

FirstActiveElement will as well, sorry I didn't include it in my comment

Oh, I see now. Yes, we shouldn't need the SpecialCodeGen for FirstActiveElement.

Ok, I actually tried it out. So 'pnext' is PNEXT <Pdn>.<T>, <Pv>, <Pdn>.<T> while 'pfirst' is PFIRST <Pdn>.B, <Pg>, <Pdn>.B. So, yea, we actually need to do SpecialCodeGen for FirstActiveElement.

hhm, not sure I am still following. Since FirstActiveElement code that you have is:

assert(isRMW); assert(HWIntrinsicInfo::IsExplicitMaskedOperation(intrin.id)); if (targetReg != op2Reg) { assert(targetReg != op1Reg); GetEmitter()->emitIns_Mov(INS_sve_mov, emitTypeSize(node), targetReg, op2Reg, /* canSkip */ true); } GetEmitter()->emitIns_R_R(ins, emitSize, targetReg, op1Reg, INS_OPTS_SCALABLE_B); break;

If we delete that, it will come on line 846, check it is isRMW and go inside if block and call emitIns_R_R(). Unless I am missing something major here.

From the line you are talking about, when the opt gets passed to emitIns_R_R, the opt is not guaranteed to be INS_OPTS_SCALABLE_B

Ok, that's where the confusion was on my part. I was looking at the unit tests and thought they both take just INS_OPTS_SCALABLE_B, but looking again at https://docsmirror.github.io/A64/2023-06/pnext_p_p_p.html, it can get other values as well. Makes sense now. Thanks!

runtime/src/coreclr/jit/codegenarm64test.cpp

Lines 5047 to 5048 in 7f7bb7b

theEmitter->emitIns_R_R(INS_sve_pnext, EA_SCALABLE, REG_P0, REG_P15,

INS_OPTS_SCALABLE_B); // PNEXT <Pdn>.<T>, <Pv>, <Pdn>.<T>

runtime/src/coreclr/jit/codegenarm64test.cpp

Lines 5034 to 5035 in 7f7bb7b

theEmitter->emitIns_R_R(INS_sve_pfirst, EA_SCALABLE, REG_P0, REG_P15,

INS_OPTS_SCALABLE_B); // PFIRST <Pdn>.B, <Pg>, <Pdn>.B

I was looking at the unit tests and thought they both take just INS_OPTS_SCALABLE_B

I did the same thing. :)

kunalspathak · 2024-06-27T06:14:51Z

src/coreclr/jit/hwintrinsiclistarm64sve.h

@@ -47,6 +47,8 @@ HARDWARE_INTRINSIC(Sve,           CreateFalseMaskSingle,
 HARDWARE_INTRINSIC(Sve,           CreateFalseMaskUInt16,                                            -1,      0,      false, {INS_invalid,        INS_invalid,        INS_invalid,        INS_sve_pfalse,     INS_invalid,        INS_invalid,        INS_invalid,        INS_invalid,        INS_invalid,        INS_invalid},     HW_Category_SIMD,                  HW_Flag_Scalable|HW_Flag_ReturnsPerElementMask)
 HARDWARE_INTRINSIC(Sve,           CreateFalseMaskUInt32,                                            -1,      0,      false, {INS_invalid,        INS_invalid,        INS_invalid,        INS_invalid,        INS_invalid,        INS_sve_pfalse,     INS_invalid,        INS_invalid,        INS_invalid,        INS_invalid},     HW_Category_SIMD,                  HW_Flag_Scalable|HW_Flag_ReturnsPerElementMask)
 HARDWARE_INTRINSIC(Sve,           CreateFalseMaskUInt64,                                            -1,      0,      false, {INS_invalid,        INS_invalid,        INS_invalid,        INS_invalid,        INS_invalid,        INS_invalid,        INS_invalid,        INS_sve_pfalse,     INS_invalid,        INS_invalid},     HW_Category_SIMD,                  HW_Flag_Scalable|HW_Flag_ReturnsPerElementMask)
+HARDWARE_INTRINSIC(Sve,           CreateMaskForFirstActiveElement,                                  -1,      2,      true,  {INS_sve_pfirst,     INS_sve_pfirst,     INS_sve_pfirst,     INS_sve_pfirst,     INS_sve_pfirst,     INS_sve_pfirst,     INS_sve_pfirst,     INS_sve_pfirst,     INS_invalid,        INS_invalid},     HW_Category_SIMD,                  HW_Flag_Scalable|HW_Flag_ExplicitMaskedOperation|HW_Flag_ReturnsPerElementMask|HW_Flag_SpecialCodeGen|HW_Flag_HasRMWSemantics)


I don't think you need SpecialCodeGen for this. They should be handled the same way CreateMaskForNextActiveElement is handled.

I have to in order to pass INS_OPTS_SCALABLE_B as part of emitting the instruction.

TIHan · 2024-06-27T23:56:38Z

@kunalspathak this is ready. Now using the ins_mov helper.

src/coreclr/jit/instr.cpp

kunalspathak · 2024-06-28T16:04:58Z

src/coreclr/jit/hwintrinsiccodegenarm64.cpp

@@ -824,7 +824,25 @@ void CodeGen::genHWIntrinsic(GenTreeHWIntrinsic* node)
                        assert(!node->IsEmbMaskOp());
                        if (HWIntrinsicInfo::IsExplicitMaskedOperation(intrin.id))
                        {
-                            GetEmitter()->emitIns_R_R_R(ins, emitSize, targetReg, op1Reg, op2Reg, opt);
+                            if (isRMW)


Why cannot NI_Sve_CreateMaskForFirstActiveElement handled here itself after you remove the SpecialCodegen flag for it. They both need INS_OPTS_SCALABLE_B as opt. So if this code can work for
NI_Sve_CreateMaskForNextActiveElement, wondering why can't it work for NI_Sve_CreateMaskForFirstActiveElement?

TIHan · 2024-06-28T18:41:45Z

@kunalspathak changed the Ins_cpy. So I guess this is ready again.

kunalspathak

LGTM

TIHan added 4 commits June 25, 2024 12:01

Initial work

844b3e2

Merge remote-tracking branch 'upstream/main' into CreateMaskForFirstA…

7919b51

…ctiveElement

Added tests. Fixed parameter names.

5cb3058

Use delay free for op1 if the target preference is op2. Use sve_mov i…

7e0a371

…nstead of mov.

dotnet-issue-labeler bot added area-System.Runtime.Intrinsics new-api-needs-documentation labels Jun 25, 2024

dotnet-policy-service bot assigned TIHan Jun 25, 2024

TIHan mentioned this pull request Jun 25, 2024

Arm64: Implement SVE APIs #99957

Closed

kunalspathak added the arm-sve Work related to arm64 SVE/SVE2 support label Jun 25, 2024

This was referenced Jun 26, 2024

Failed USB connection via port 54050, error 61, in tvOS arm64 Release AllSubsets_Mono #82637

Open

The Operation will be canceled. The next steps may not contain expected logs. dotnet/dnceng#3008

Open

a74nh reviewed Jun 26, 2024

View reviewed changes

kunalspathak requested changes Jun 26, 2024

View reviewed changes

TIHan added 2 commits June 26, 2024 12:17

Feedback

f913b66

Feedback

91a0202

TIHan added 3 commits June 26, 2024 12:49

Update Helpers.cs

22b5851

Handle RMW for non-explicit masked operation

9aa4333

Remove handling as its already handled it looks like

5985bbd

kunalspathak reviewed Jun 26, 2024

View reviewed changes

src/coreclr/jit/hwintrinsiccodegenarm64.cpp Outdated Show resolved Hide resolved

Feedback

615296d

This was referenced Jun 27, 2024

[browser][MT] WasmBrowserTestRunner.RunConsoleMessagesPump - abrupt disconect #101618

Closed

[browser][MT] System.Net.Http.Functional.Tests.WorkItemExecution timeout #102385

Closed

[browser][MT] test failure: Tests timed out. Killing driver service #103524

Open

kunalspathak reviewed Jun 27, 2024

View reviewed changes

TIHan added 2 commits June 27, 2024 16:52

Feedback

42abb9e

Merging

f6e8bc6

kunalspathak reviewed Jun 28, 2024

View reviewed changes

Feedback

ef88f08

kunalspathak approved these changes Jun 28, 2024

View reviewed changes

kunalspathak closed this Jun 28, 2024

kunalspathak reopened this Jun 28, 2024

This was referenced Jun 29, 2024

TimeProviderTests.TestProviderTimer failed in CI #103459

Closed

System.Numerics.Tensors.Tests.TensorSpanTests test failure #103525

Closed

kunalspathak merged commit 3a294ed into dotnet:main Jun 29, 2024
162 of 167 checks passed

kunalspathak mentioned this pull request Jul 16, 2024

JIT: Added Sve.CreateBreakPropagateMask #104704

Merged

build-analysis bot mentioned this pull request Jul 21, 2024

tracing/eventpipe/eventsourceerror/eventsourceerror/eventsourceerror failure #80666

Closed

github-actions bot locked and limited conversation to collaborators Jul 29, 2024

	theEmitter->emitIns_R_R(INS_sve_pnext, EA_SCALABLE, REG_P0, REG_P15,
	INS_OPTS_SCALABLE_B); // PNEXT <Pdn>.<T>, <Pv>, <Pdn>.<T>

	theEmitter->emitIns_R_R(INS_sve_pfirst, EA_SCALABLE, REG_P0, REG_P15,
	INS_OPTS_SCALABLE_B); // PFIRST <Pdn>.B, <Pg>, <Pdn>.B

JIT: Added SVE APIs CreateMaskForFirstActiveElement and CreateMaskForNextActiveElement #104002

JIT: Added SVE APIs CreateMaskForFirstActiveElement and CreateMaskForNextActiveElement #104002

Conversation

TIHan commented Jun 25, 2024

dotnet-issue-labeler bot commented Jun 25, 2024

dotnet-issue-labeler bot commented Jun 25, 2024

dotnet-policy-service bot commented Jun 25, 2024

TIHan commented Jun 25, 2024 • edited Loading

tannergooding commented Jun 26, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

TIHan commented Jun 26, 2024 • edited Loading

TIHan commented Jun 26, 2024

Choose a reason for hiding this comment

TIHan Jun 27, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

TIHan commented Jun 27, 2024

Choose a reason for hiding this comment

TIHan commented Jun 28, 2024

kunalspathak left a comment

Choose a reason for hiding this comment

JIT: Added SVE APIs `CreateMaskForFirstActiveElement` and `CreateMaskForNextActiveElement` #104002

JIT: Added SVE APIs `CreateMaskForFirstActiveElement` and `CreateMaskForNextActiveElement` #104002

TIHan commented Jun 25, 2024 •

edited

Loading

TIHan commented Jun 26, 2024 •

edited

Loading

TIHan Jun 27, 2024 •

edited

Loading