-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[mono][mini] Interlocked.CompareExchange and Interlocked.Exchange intrinsics for small types and enums #106660
Conversation
also add mono_atomic_cas_u8 utility function
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interp parts look correct to me.
@kg do you want to do the jiterp work here or in a follow up? |
Jiterp implementation should be done already, I pushed it into the PR. |
for all i/u 4 variants? |
i/u 4 variants aren't in this PR, I think? They're on the todo list. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
arm changes look good to me
@@ -44,6 +45,10 @@ | |||
</MonoAOTCompiler> | |||
</Target> | |||
|
|||
<ItemGroup> | |||
<ProjectReference Include="$(RepoTasksDir)AotCompilerTask\MonoAOTCompiler.csproj" ReferenceOutputAssembly="false" Condition="'$(RunAOTCompilation)' == 'true'" AdditionalProperties="Configuration=Debug"/> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For my education, why those changes were necessary? I thought we could already run the mono sample with FullAOT
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
./build.sh mono+libs+tasks
on OSX it doesn't bulid the AOT compiler task anymore because someone added a condition to tasks.proj
to skip it on non-mobile platforms. I think the long-term direction for tasks.proj is to get rid of it and add proper project references to all the projects that need tasks
|
OPDEF(MINT_MONO_EXCHANGE_U1, "mono_interlocked.xchg.u1", 4, 1, 2, MintOpNoArgs) | ||
OPDEF(MINT_MONO_EXCHANGE_I1, "mono_interlocked.xchg.i1", 4, 1, 2, MintOpNoArgs) | ||
OPDEF(MINT_MONO_EXCHANGE_U2, "mono_interlocked.xchg.u2", 4, 1, 2, MintOpNoArgs) | ||
OPDEF(MINT_MONO_EXCHANGE_I2, "mono_interlocked.xchg.i2", 4, 1, 2, MintOpNoArgs) | ||
OPDEF(MINT_MONO_EXCHANGE_I4, "mono_interlocked.xchg.i4", 4, 1, 2, MintOpNoArgs) | ||
OPDEF(MINT_MONO_EXCHANGE_I8, "mono_interlocked.xchg.i8", 4, 1, 2, MintOpNoArgs) | ||
OPDEF(MINT_MONO_CMPXCHG_U1, "mono_interlocked.cmpxchg.u1", 5, 1, 3, MintOpNoArgs) | ||
OPDEF(MINT_MONO_CMPXCHG_I1, "mono_interlocked.cmpxchg.i1", 5, 1, 3, MintOpNoArgs) | ||
OPDEF(MINT_MONO_CMPXCHG_U2, "mono_interlocked.cmpxchg.u2", 5, 1, 3, MintOpNoArgs) | ||
OPDEF(MINT_MONO_CMPXCHG_I2, "mono_interlocked.cmpxchg.i2", 5, 1, 3, MintOpNoArgs) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@BrzVlad @kg instead of having a ton of different opcodes, we could have a single MINT_MONO_EXCHANGE_INT
(and MINT_MONO_CMPXCHG_INT
) opcode with a isSigned << 4 | size
byte argument. That would make the big opcode switch in interp.c a little smaller, but make the code a little more complicated. Any opinions about which way is better?
/backport to release/9.0 |
Started backporting to release/9.0: https://github.com/dotnet/runtime/actions/runs/10531732073 |
Thank you, @lamdageek. |
Only arm64, amd64 and WebAssembly. Interpreter, JIT and LLVM AOT. No x86 or arm32.
The complication for the 8- and 16-bit operands is that the .NET operand stack is 32-bit. so we have to zero- or sign-extend the inputs and output.
I ended up following the same approach as clang: zero-extend "expected" value and then sign-extend the return value of the CAS. One nice consequence is that the LLVM support is essentially free.
Also this PR makes the intrinsic apply to types that have byte/int/long as the underlying type (bool, enums) not just when the type is literally in the signature
TODO:
Interlocked.Exchange(int)
intrinsicsRelated to #105335
Related to #93488