Allow more than 64 ISA flags for jit interface. #73965

DeepakRajendrakumaran · 2022-08-15T20:27:17Z

Currently since _flags is a 64 bit variable, only 64 ISAs can be represented using this design. This change makes this an array thus enabling us to represent more than 64 ISAs.

ghost · 2022-08-15T20:27:33Z

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

Issue Details

Currently since _flags is a 64 bit variable, only 64 ISAs can be represented using this design. This change makes this an array thus enabling us to represent more than 64 ISAs.

Author:	DeepakRajendrakumaran
Assignees:	-
Labels:	`area-CodeGen-coreclr`
Milestone:	-

DeepakRajendrakumaran · 2022-08-15T20:28:00Z

@BruceForstall @tannergooding

tannergooding · 2022-08-16T17:38:40Z

CC. @davidwrighton and @dotnet/crossgen-contrib

This needs review and sign-off to ensure this doesn't negatively impact the CG2 scenarios. Please call out any other outerloop validation that should be done as well.

jakobbotsch · 2022-08-16T17:45:14Z

src/coreclr/inc/corinfoinstructionset.h

 public:
+    static const int FlagsArrSize = 1;


Move this up to the beginning of the struct and use it in the definition of _flags?

Yes, will move FlagsArrSize . It is currently used for definition of _flags but I'm using the actual calculated value instead of the variable since we know at the time of generating this file what the value is. But I don't see a problem with switching to var as you suggested.

Slight correction here - the reason FlagsArrSize is currently public is because it's used from compiler.h. I see that you have another comment there. Will address that first before changing this.

src/coreclr/inc/corinfoinstructionset.h

jakobbotsch · 2022-08-16T17:47:42Z

src/coreclr/jit/compiler.h

@@ -8966,19 +8973,23 @@ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
        JitFlags* jitFlags; // all flags passed from the EE

        // The instruction sets that the compiler is allowed to emit.
-        uint64_t compSupportsISA;
+        uint64_t compSupportsISA[CORINFO_InstructionSetFlags::FlagsArrSize];


Is there any reason we cannot use CORINFO_InstructionSetFlags here and avoid all this manual bit fiddling when setting/getting members?

Do you mean have this as following and use the CORINFO_InstructionSetFlags methods to do the manipulation?

CORINFO_InstructionSetFlags compSupportsISA; .......................... CORINFO_InstructionSetFlags compSupportsISAReported; ........................ CORINFO_InstructionSetFlags compSupportsISAExactly;

Yep, exactly.

Got it! Changed

jakobbotsch · 2022-08-16T17:49:09Z

src/coreclr/tools/Common/JitInterface/CorInfoInstructionSet.cs

+        private static int _flagsArrSize = 1;
+        private fixed ulong _flags[1];


Seems this can use a const too.

BruceForstall

I don't have any specific suggestions in addition to @jakobbotsch .

I'd like to see if we can reduce the number of uses of the "Raw" APIs, but that's for a follow-up.

BruceForstall · 2022-08-17T19:54:13Z

src/coreclr/inc/corinfoinstructionset.h

-        _flags = _flags | (((uint64_t)1) << instructionSet);
+        int arrayIdx = instructionSet / 64;
+        int bit = instructionSet % 64;
+        _flags[arrayIdx] = _flags[arrayIdx] | (((uint64_t)1) << bit);


nit: use |= ?

Suggested change

_flags[arrayIdx] = _flags[arrayIdx] | (((uint64_t)1) << bit);

_flags[arrayIdx] |= ((uint64_t)1) << bit;

BruceForstall · 2022-08-17T19:54:49Z

src/coreclr/inc/corinfoinstructionset.h

-        _flags = _flags & ~(((uint64_t)1) << instructionSet);
+        int arrayIdx = instructionSet / 64;
+        int bit = instructionSet % 64;
+        _flags[arrayIdx] = _flags[arrayIdx] & ~(((uint64_t)1) << bit);


Suggested change

_flags[arrayIdx] = _flags[arrayIdx] & ~(((uint64_t)1) << bit);

_flags[arrayIdx] &= ~(((uint64_t)1) << bit);

BruceForstall

This LGTM. It'd like @davidwrighton to take a look at the AOT side.

BruceForstall · 2022-08-17T23:17:56Z

BTW, is it reasonable to convert this from a "Draft" to a "normal" PR? Normally, I think of "Draft" as something that is not ready to be reviewed.

DeepakRajendrakumaran · 2022-08-17T23:28:27Z

BTW, is it reasonable to convert this from a "Draft" to a "normal" PR? Normally, I think of "Draft" as something that is not ready to be reviewed.

Yes, this is ready to be reviewed and I've taken out the 'draft' tag. Will keep this in mind for newer PRs(i.e., tagging as draft initially to see test run results and if it broke something unexpected and then removing 'draft' tag once it looks good)

src/coreclr/tools/Common/JitInterface/CorInfoInstructionSet.cs

jkotas · 2022-08-18T07:27:15Z

src/coreclr/tools/Common/JitInterface/CorInfoInstructionSet.cs

        public void AddInstructionSet(InstructionSet instructionSet)
        {
-            _flags = _flags | (((ulong)1) << (int)instructionSet);
+            int arrayIdx = (int)instructionSet / 64;


It is better to use uint in this pattern. Signed division is less efficient.

Ah. Good catch- it's a power of 2 division. Changed

src/coreclr/inc/corinfoinstructionset.h

tannergooding · 2022-08-18T13:52:05Z

src/coreclr/inc/corinfoinstructionset.h

+    uint64_t* GetFlagsRaw()
    {
        return _flags;
    }

-    void SetFromFlagsRaw(uint64_t flags)
+    void SetFromFlagsRaw(uint64_t* flags)
    {
-        _flags = flags;
+        for (int i = 0; i < FlagsArrSize; i++)
+        {
+            _flags[i] = flags[i];
+        }
    }


Do we want/need to still allow getting the raw flags? I think we could just return and enforce usage of CORINFO_InstructionSetFlags instead.

It looks like the "raw" APIs are really only used from class CORJIT_FLAGS and setSupportedISAs which normally abstracts away the underlying CORINFO_InstructionSetFlags.

Agreed that it makes sense to remove the SetFromFlagsRaw but GetFlagsRaw is used from SuperPMI(see changes in src/coreclr/tools/superpmi/superpmi-shared/methodcontext.cpp). I might be missing something here but I am not sure how I can work around that.

src/coreclr/tools/Common/JitInterface/ThunkGenerator/InstructionSetGenerator.cs

BruceForstall · 2022-08-19T17:49:40Z

@DeepakRajendrakumaran Can you fix the JIT formatting? (See the "Formatting" job failures)

Also, there are some SuperPMI asm diffs:

https://dev.azure.com/dnceng/public/_build/results?buildId=1952690&view=ms.vss-build-web.run-extensions-tab

I would expect this change to not have any asm diffs. Agreed?

DeepakRajendrakumaran · 2022-08-19T17:53:35Z

@DeepakRajendrakumaran Can you fix the JIT formatting? (See the "Formatting" job failures)

Also, there are some SuperPMI asm diffs:

https://dev.azure.com/dnceng/public/_build/results?buildId=1952690&view=ms.vss-build-web.run-extensions-tab

I would expect this change to not have any asm diffs. Agreed?

There is a small change in the SuperPMI tool but it ideally shouldn't have any effect as far as I understand. Will check it out.

BruceForstall · 2022-08-19T18:01:46Z

Ah, you've changed CORINFO_InstructionSetFlags and thus CORJIT_FLAGS, which is passed across the JIT interface. You should change the JIT-EE GUID in jiteeversionguid.h.

I thought your change wouldn't change data layout so maybe it should "just work" with a SPMI collection with the previous layout, but maybe not?

BruceForstall · 2022-08-19T18:25:37Z

src/coreclr/inc/corinfoinstructionset.h

+
+    static uint64_t GetRelativeBitIndex(CORINFO_InstructionSet instructionSet)
+    {
+        return ((uint64_t)1) << (instructionSet & 0x3F);


This looks like a bug, since it ignores the top 2 bits

Suggested change

return ((uint64_t)1) << (instructionSet & 0x3F);

uint32_t bitIndex = (uint32_t)instructionSet;

return (uint32_t)(bitIndex % (uint32_t)BitsPerFlagsField);

GetFlagsFieldIndex gets the 64-bit field in which a given instructionSet is tagged (only the bits 6 and higher matter).

GetRelativeBitIndex then gets the bit offset within that field, which can only be 0-63, so 0x3F should be the correct mask.

GetRelativeBitMask might have been a better name, since its not getting the index but rather a mask that only includes the given index.

Have changed name to GetRelativeBitMask

BruceForstall · 2022-08-19T18:27:54Z

src/coreclr/tools/Common/JitInterface/CorInfoInstructionSet.cs

+
+        private static ulong GetRelativeBitIndex(InstructionSet instructionSet)
+        {
+            return ((ulong)1) << ((int)instructionSet & 0x3F);


Suggested change

return ((ulong)1) << ((int)instructionSet & 0x3F);

uint bitIndex = (uint)instructionSet;

return (uint)(bitIndex % (uint)BitsPerFlagsField);

BruceForstall · 2022-08-19T18:29:13Z

src/coreclr/tools/Common/JitInterface/ThunkGenerator/InstructionSetGenerator.cs

+
+        private static ulong GetRelativeBitIndex(InstructionSet instructionSet)
+        {
+            return ((ulong)1) << ((int)instructionSet & 0x3F);


Suggested change

return ((ulong)1) << ((int)instructionSet & 0x3F);

uint bitIndex = (uint)instructionSet;

return (uint)(bitIndex % (uint)BitsPerFlagsField);

BruceForstall · 2022-08-19T18:30:16Z

src/coreclr/tools/Common/JitInterface/ThunkGenerator/InstructionSetGenerator.cs

+
+    static uint64_t GetRelativeBitIndex(CORINFO_InstructionSet instructionSet)
+    {
+        return ((uint64_t)1) << (instructionSet & 0x3F);


Suggested change

return ((uint64_t)1) << (instructionSet & 0x3F);

uint32_t bitIndex = (uint32_t)instructionSet;

return (uint32_t)(bitIndex % (uint32_t)BitsPerFlagsField);

DeepakRajendrakumaran · 2022-08-19T18:55:37Z

CORINFO_InstructionSetFlags

Another question is, right now I'm just copying the struct(CORINFO_InstructionSetFlags ) when I have to. It has an array and an integer as fields now so shouldn't be a problem. Do you think it makes sense to add a copy constructor to explicitly copy the struct content in case some other field gets added in future which possibly causes an issue here or do I just leave it as is?

Refer src/coreclr/jit/jitee.h for example

DeepakRajendrakumaran · 2022-08-19T22:38:58Z

Ah, you've changed CORINFO_InstructionSetFlags and thus CORJIT_FLAGS, which is passed across the JIT interface. You should change the JIT-EE GUID in jiteeversionguid.h.

I thought your change wouldn't change data layout so maybe it should "just work" with a SPMI collection with the previous layout, but maybe not?

Yeah. I didn't excpect any changes. I followed the instruction here(link) and ran the following

superpmi.py asmdiffs -target_os windows -target_arch x64 -arch x64

Users\deepakra\Dotnet\runtime>python src\coreclr\scripts\superpmi.py  asmdiffs -core_root=C:\Users\deepakra\Dotnet\runtime\artifacts\tests\coreclr\windows.x64.Debug\Tests\Core_Root -target_os windows -target_arch x64 -arch x64
[15:28:31] ================ Logging to C:\Users\deepakra\Dotnet\runtime\artifacts\spmi\superpmi.2.log
[15:28:31] Using JIT/EE Version from jiteeversionguid.h: 1b9551b8-21f4-4233-9c90-f3eabd6a322b
[15:28:31] Baseline hash: f142128e89b63577a9bbba7e2b760ec82102a7a9
[15:28:31] Using baseline C:\Users\deepakra\Dotnet\runtime\artifacts\spmi\basejit\080f708e7018f6c0529b6c875a44d84fc4d74419.windows.x64.Checked\clrjit.dll
[15:28:31] Using coredistools found at C:\Users\deepakra\Dotnet\runtime\artifacts\tests\coreclr\windows.x64.Debug\Tests\Core_Root\coredistools.dll
[15:28:31] Found download cache directory "C:\Users\deepakra\Dotnet\runtime\artifacts\spmi\mch\1b9551b8-21f4-4233-9c90-f3eabd6a322b.windows.x64" and --force_download not set; skipping download
[15:28:31] SuperPMI ASM diffs
[15:28:31] Base JIT Path: C:\Users\deepakra\Dotnet\runtime\artifacts\spmi\basejit\080f708e7018f6c0529b6c875a44d84fc4d74419.windows.x64.Checked\clrjit.dll
[15:28:31] Diff JIT Path: C:\Users\deepakra\Dotnet\runtime\artifacts\tests\coreclr\windows.x64.Debug\Tests\Core_Root\clrjit.dll
[15:28:31] Using MCH files:
[15:28:31]   C:\Users\deepakra\Dotnet\runtime\artifacts\spmi\mch\1b9551b8-21f4-4233-9c90-f3eabd6a322b.windows.x64\aspnet.run.windows.x64.checked.mch
[15:28:31]   C:\Users\deepakra\Dotnet\runtime\artifacts\spmi\mch\1b9551b8-21f4-4233-9c90-f3eabd6a322b.windows.x64\benchmarks.run.windows.x64.checked.mch
[15:28:31]   C:\Users\deepakra\Dotnet\runtime\artifacts\spmi\mch\1b9551b8-21f4-4233-9c90-f3eabd6a322b.windows.x64\coreclr_tests.pmi.windows.x64.checked.mch
[15:28:31]   C:\Users\deepakra\Dotnet\runtime\artifacts\spmi\mch\1b9551b8-21f4-4233-9c90-f3eabd6a322b.windows.x64\libraries.crossgen2.windows.x64.checked.mch
[15:28:31]   C:\Users\deepakra\Dotnet\runtime\artifacts\spmi\mch\1b9551b8-21f4-4233-9c90-f3eabd6a322b.windows.x64\libraries.pmi.windows.x64.checked.mch
[15:28:31]   C:\Users\deepakra\Dotnet\runtime\artifacts\spmi\mch\1b9551b8-21f4-4233-9c90-f3eabd6a322b.windows.x64\libraries_tests.pmi.windows.x64.checked.mch
[15:28:31] Running asm diffs of C:\Users\deepakra\Dotnet\runtime\artifacts\spmi\mch\1b9551b8-21f4-4233-9c90-f3eabd6a322b.windows.x64\aspnet.run.windows.x64.checked.mch
[15:29:10] Clean SuperPMI diff (126706 contexts processed)
[15:29:10] Running asm diffs of C:\Users\deepakra\Dotnet\runtime\artifacts\spmi\mch\1b9551b8-21f4-4233-9c90-f3eabd6a322b.windows.x64\benchmarks.run.windows.x64.checked.mch
[15:29:25] Clean SuperPMI diff (38864 contexts processed)
[15:29:25] Running asm diffs of C:\Users\deepakra\Dotnet\runtime\artifacts\spmi\mch\1b9551b8-21f4-4233-9c90-f3eabd6a322b.windows.x64\coreclr_tests.pmi.windows.x64.checked.mch
[15:31:59] Clean SuperPMI diff (255160 contexts processed)
[15:31:59] Running asm diffs of C:\Users\deepakra\Dotnet\runtime\artifacts\spmi\mch\1b9551b8-21f4-4233-9c90-f3eabd6a322b.windows.x64\libraries.crossgen2.windows.x64.checked.mch
[15:32:35] Clean SuperPMI diff (224125 contexts processed)
[15:32:35] Running asm diffs of C:\Users\deepakra\Dotnet\runtime\artifacts\spmi\mch\1b9551b8-21f4-4233-9c90-f3eabd6a322b.windows.x64\libraries.pmi.windows.x64.checked.mch
[15:33:37] Clean SuperPMI diff (250246 contexts processed)
[15:33:37] Running asm diffs of C:\Users\deepakra\Dotnet\runtime\artifacts\spmi\mch\1b9551b8-21f4-4233-9c90-f3eabd6a322b.windows.x64\libraries_tests.pmi.windows.x64.checked.mch
[15:35:47] Clean SuperPMI diff (331817 contexts processed)
[15:35:47] Asm diffs summary:
[15:35:47]   No asm diffs

I take the last line No asm diffs to mean that there is no diff

BruceForstall · 2022-08-19T23:16:53Z

I take the last line No asm diffs to mean that there is no diff

True. I wonder why the superpmi-diffs jobs showed diffs.

Note that now that you've changed the JIT-EE GUID, you won't be able to run SuperPMI diffs.

python src\coreclr\scripts\superpmi.py asmdiffs -core_root=C:\Users\deepakra\Dotnet\runtime\artifacts\tests\coreclr\windows.x64.Debug\Tests\Core_Root -target_os windows -target_arch x64 -arch x64

Normally, I would recommend using a Checked build (just because it's faster).

Also, if you're on a Windows x64 machine, the -target_os / -target_arch / -arch will be defaulted as you've specified.

DeepakRajendrakumaran · 2022-08-22T20:50:34Z

True. I wonder why the superpmi-diffs jobs showed diffs.

Is this something you have seen before with JITInterface changes?(specifically this - No textual differences. Is this an issue with coredistools?)

Note that now that you've changed the JIT-EE GUID, you won't be able to run SuperPMI diffs.

This makes it difficult to check the original failures. Is there some way to see the original SuperPMI failures we need to look at/fix? Or do I have to revert this temporarily and get the CI to re-run everything?

BruceForstall · 2022-08-22T21:14:22Z

I wonder why the superpmi-diffs jobs showed diffs.

It turns out we realized late last week that our automatic JIT baseline build system wasn't working properly. That should now be fixed. If you rebase on top of current main (and re-push), the system should pick up a current baseline.

Or do I have to revert this temporarily and get the CI to re-run everything?

It might make sense to temporarily revert the JIT-EE version GUID change if you want to re-run testing. Note this will only work if there is no binary difference in the JIT-EE traffic (including the CORFLAGS stuff), which I believe should be the case with your change.

DeepakRajendrakumaran · 2022-08-23T15:53:59Z

It might make sense to temporarily revert the JIT-EE version GUID change if you want to re-run testing. Note this will only work if there is no binary difference in the JIT-EE traffic (including the CORFLAGS stuff), which I believe should be the case with your change.

Yep. It worked. All tests passed. I'll remove the 'revert' commit and change GetRelativeBitIndex to GetRelativeBitMask as per the conversation above.

jakobbotsch · 2022-08-23T16:01:48Z

I didn't read the full thread -- is the JIT-EE GUID change still necessary now that we established the diffs were spurious?

BruceForstall · 2022-08-23T16:08:18Z

I didn't read the full thread -- is the JIT-EE GUID change still necessary now that we established the diffs were spurious?

It's a fair question. The data representation changed, but at least currently in a binary identical way. When the number of flags is increased, we'll certainly need to change the GUID.

So for now, it's ok not to change the GUID (and not changing it leads to less churn).

DeepakRajendrakumaran · 2022-08-23T16:12:54Z

I didn't read the full thread -- is the JIT-EE GUID change still necessary now that we established the diffs were spurious?

In the GUID file it says

This GUID represents the version of the JIT/EE interface. Any time the interface between the JIT and the EE changes (by adding or removing methods to any interface shared between them), this GUID should be changed. This is the identifier verified by ICorJitCompiler::getVersionIdentifier().

Also from updating-jitinterface.md

The JitInterface is versioned by a GUID. Any change to JitInterface is required to update the JitInterface GUID located in jiteeversionguid.h (look for JITEEVersionIdentifier). Not doing so has consequences that are sometimes hard to debug.

There has been some changes in the interface code. But as you pointed out, no diff changes exist. So, I'll leave it to the reviewers to decide. :)

Edit : Didn't see the reply above when I posted this comment. Will follow the guidance there.

Details: Previously ISA flags were represented as bits in a 64 bit variable. This limited the total number of possible ISAs to 64. This change modifies this and starts using an array of 64 bit vars to store ISA flags. The main changes are in InstructionSetGenerator.cs. This drives a lot of other changes in this commit which are generated files.

BruceForstall · 2022-08-23T23:01:17Z

CC. @davidwrighton and @dotnet/crossgen-contrib

This needs review and sign-off to ensure this doesn't negatively impact the CG2 scenarios. Please call out any other outerloop validation that should be done as well.

@dotnet/crossgen-contrib @davidwrighton @trylek -- Anyone want to take a look at this JIT-EE interface format change for potential crossgen2 impact?

trylek

As no jitinterface changes are part of this PR, I believe our only interaction with the JIT flags is in JitConfigProvider and we seem to be consistently using CorJitFlag arrays to represent them; I believe this change should have zero Crossgen2 impact.

tannergooding · 2022-08-24T01:09:58Z

@trylek, are there any concerns with how this will impact crossgen each time we do need to increase the field count?

We are definitely going to need at least 2 fields for the .NET 8 AVX-512 work, so ensuring that this schema will work and work over time without too much additional effort is also important.

Ideally simply changing the FlagsFieldCount and potentially JIT/EE Version GUID should be enough. If there are additional changes needed in such a scenario, such as documenting a R2R metadata format version change, we should ensure its covered in the generation script so its visible as part of the required work anytime this changes.

trylek · 2022-08-24T16:00:39Z

@tannergooding - going over the code a second time I have found one place where we still manipulate JIT flags using the uint64 bit mask:

runtime/src/coreclr/tools/Common/JitInterface/CorInfoTypes.cs

Line 1435 in 8641256

private UInt64 _corJitFlags;

In Crossgen2 its only users seem to be two places that use the IsSet method to check for CORJIT_FLAG_IL_STUB; I'm not sure about its use in NativeAOT, @MichalStrehovsky should know.

To my knowledge today Crossgen2 doesn't support command-line parameters for specifying arbitrary JIT flags, it only uses about a dozen flags that are hard-coded in the source code (a bunch of flags affecting optimizations, instruction sets and the like). From this viewpoint future extensions of Crossgen2 support for JIT flags may be twofold:

Modifying the source code to set additional JIT flags in certain situations. If the developer decides to use the CORJIT_FLAGS struct with a flag with index greater than or equal to 64, they'll need to fix its implementation. Please note that they don't really have to, JitConfigProvider implement a method HasFlag that doesn't have the 64-bit limitation (it searches the array) at the expense of slightly lower performance.
Adding command line support for specifying arbitrary JIT flags, perhaps by using their indices or a hexadecimal bit mask. Its actual implementation may need to further tweak the existing code manipulating JIT flags but likely in a very minimal manner.

tannergooding · 2022-08-24T16:09:03Z

@trylek Thanks for the explanation!

To my knowledge today Crossgen2 doesn't support command-line parameters for specifying arbitrary JIT flags, it only uses about a dozen flags that are hard-coded in the source code (a bunch of flags affecting optimizations, instruction sets and the like).

In particular, I was considering the metadata used to track the instruction sets that a given method uses (required vs opportunistic). I believe this is related to the InstructionSetFlags field (rather than the _corJitFlags field):

runtime/src/coreclr/tools/Common/JitInterface/CorInfoTypes.cs

Line 1436 in 8641256

public InstructionSetFlags InstructionSetFlags;

Extending the number of CORINFO_InstructionSet enum entries beyond 64 means that an additional field is required to track which instruction sets a given method needs and that would in turn impact the R2R metadata version, as far as I'm aware.

trylek · 2022-08-24T16:16:53Z

I believe that today implementation of instruction sets uses ReadyToRun fixups, the exact encoding is implemented here:

runtime/src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/DependencyAnalysis/ReadyToRun/ReadyToRunInstructionSetSupportSignature.cs

Line 90 in 8641256

foreach (string instructionSetString in instructionSetsSupported)

As you can easily see, it doesn't have the 64-bit limitation as it encodes the individual instruction sets as signature-encoded uints.

You are right that we'd need to revamp the R2R format if we wanted to support multitargeting compilation (where a function could have several implementations compiled for various instruction sets and a suitable version would be picked dynamically at runtime) but that would be a completely new feature so it would require design in any case.

tannergooding · 2022-08-24T16:18:46Z

Thanks for confirming. Just wanted to ensure that us going over wasn't going to cause unexpected breakages in R2R due to some missed edge case.

@BruceForstall, I think this is ready to merge then once your "change requested" is resolved.

dotnet-issue-labeler bot added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Aug 15, 2022

ghost added the community-contribution Indicates that the PR has been added by a community member label Aug 15, 2022

DeepakRajendrakumaran force-pushed the Issue163 branch from c502277 to 54860ef Compare August 16, 2022 17:31

jakobbotsch reviewed Aug 16, 2022

View reviewed changes

DeepakRajendrakumaran force-pushed the Issue163 branch from 54860ef to db63099 Compare August 16, 2022 22:34

BruceForstall requested changes Aug 17, 2022

View reviewed changes

ghost added the needs-author-action An issue or pull request that requires more info or actions from the author. label Aug 17, 2022

BruceForstall reviewed Aug 17, 2022

View reviewed changes

DeepakRajendrakumaran force-pushed the Issue163 branch from db63099 to 21f93aa Compare August 17, 2022 22:43

ghost removed the needs-author-action An issue or pull request that requires more info or actions from the author. label Aug 17, 2022

DeepakRajendrakumaran force-pushed the Issue163 branch from 21f93aa to 47a064e Compare August 17, 2022 22:46

BruceForstall reviewed Aug 17, 2022

View reviewed changes

DeepakRajendrakumaran marked this pull request as ready for review August 17, 2022 23:24

DeepakRajendrakumaran requested a review from MichalStrehovsky as a code owner August 17, 2022 23:24

jkotas reviewed Aug 18, 2022

View reviewed changes

src/coreclr/tools/Common/JitInterface/CorInfoInstructionSet.cs Outdated Show resolved Hide resolved

jkotas reviewed Aug 18, 2022

View reviewed changes

tannergooding reviewed Aug 18, 2022

View reviewed changes

src/coreclr/inc/corinfoinstructionset.h Outdated Show resolved Hide resolved

tannergooding reviewed Aug 18, 2022

View reviewed changes

src/coreclr/inc/corinfoinstructionset.h Outdated Show resolved Hide resolved

tannergooding reviewed Aug 18, 2022

View reviewed changes

src/coreclr/tools/Common/JitInterface/ThunkGenerator/InstructionSetGenerator.cs Outdated Show resolved Hide resolved

tannergooding reviewed Aug 18, 2022

View reviewed changes

src/coreclr/tools/Common/JitInterface/ThunkGenerator/InstructionSetGenerator.cs Outdated Show resolved Hide resolved

JulieLeeMSFT added this to the 8.0.0 milestone Aug 18, 2022

DeepakRajendrakumaran force-pushed the Issue163 branch 2 times, most recently from cbf2c55 to 043aae7 Compare August 18, 2022 23:13

BruceForstall requested changes Aug 19, 2022

View reviewed changes

ghost added the needs-author-action An issue or pull request that requires more info or actions from the author. label Aug 19, 2022

ghost removed the needs-author-action An issue or pull request that requires more info or actions from the author. label Aug 19, 2022

DeepakRajendrakumaran force-pushed the Issue163 branch from 043aae7 to 6cb3350 Compare August 19, 2022 19:43

runfoapp bot mentioned this pull request Aug 19, 2022

system.collections.concurrent.tests failed in CI #73038

Closed

DeepakRajendrakumaran force-pushed the Issue163 branch from b0fa75d to 5386480 Compare August 22, 2022 22:12

DeepakRajendrakumaran force-pushed the Issue163 branch from 5386480 to efc70f7 Compare August 23, 2022 16:51

trylek approved these changes Aug 23, 2022

View reviewed changes

BruceForstall approved these changes Aug 24, 2022

View reviewed changes

BruceForstall merged commit 040c7bd into dotnet:main Aug 24, 2022

ghost locked as resolved and limited conversation to collaborators Sep 23, 2022

BruceForstall added the avx512 Related to the AVX-512 architecture label Mar 27, 2023

		private static int _flagsArrSize = 1;
		private fixed ulong _flags[1];

	_flags[arrayIdx] = _flags[arrayIdx] \| (((uint64_t)1) << bit);
	_flags[arrayIdx] \|= ((uint64_t)1) << bit;

	_flags[arrayIdx] = _flags[arrayIdx] & ~(((uint64_t)1) << bit);
	_flags[arrayIdx] &= ~(((uint64_t)1) << bit);

	return ((uint64_t)1) << (instructionSet & 0x3F);
	uint32_t bitIndex = (uint32_t)instructionSet;
	return (uint32_t)(bitIndex % (uint32_t)BitsPerFlagsField);

	return ((ulong)1) << ((int)instructionSet & 0x3F);
	uint bitIndex = (uint)instructionSet;
	return (uint)(bitIndex % (uint)BitsPerFlagsField);

Allow more than 64 ISA flags for jit interface. #73965

Allow more than 64 ISA flags for jit interface. #73965

Conversation

DeepakRajendrakumaran commented Aug 15, 2022

ghost commented Aug 15, 2022

DeepakRajendrakumaran commented Aug 15, 2022

tannergooding commented Aug 16, 2022

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

BruceForstall left a 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

BruceForstall left a comment

Choose a reason for hiding this comment

BruceForstall commented Aug 17, 2022

DeepakRajendrakumaran commented Aug 17, 2022

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

BruceForstall commented Aug 19, 2022

DeepakRajendrakumaran commented Aug 19, 2022

BruceForstall commented Aug 19, 2022

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

DeepakRajendrakumaran commented Aug 19, 2022

DeepakRajendrakumaran commented Aug 19, 2022 • edited Loading

BruceForstall commented Aug 19, 2022

DeepakRajendrakumaran commented Aug 22, 2022

BruceForstall commented Aug 22, 2022

DeepakRajendrakumaran commented Aug 23, 2022

jakobbotsch commented Aug 23, 2022

BruceForstall commented Aug 23, 2022

DeepakRajendrakumaran commented Aug 23, 2022 • edited Loading

BruceForstall commented Aug 23, 2022

trylek left a comment

Choose a reason for hiding this comment

tannergooding commented Aug 24, 2022

trylek commented Aug 24, 2022

tannergooding commented Aug 24, 2022

trylek commented Aug 24, 2022

tannergooding commented Aug 24, 2022

DeepakRajendrakumaran commented Aug 19, 2022 •

edited

Loading

DeepakRajendrakumaran commented Aug 23, 2022 •

edited

Loading