[WIP][mono] Basic SIMD support for System.Numerics.Vector2 on arm64 #91455
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ghost
assigned 
|
More paths where 128-bit vector specific code is used detected (e.g. |
matouskozak
changed the title
You can use a |
The ILLink ProjectReference output shouldn't be copied to consuming projects. From the docs: > Private Optional boolean. Specifies whether the reference should be copied to the output folder. This attribute matches the Copy Local property of the reference that's in the Visual Studio IDE.
* [ARM64] Add g_GCShadowEnd to JIT_WriteBarrier_Table This change moves address of g_GCShadowEnd to JIT_WriteBarrier_Table like others variables used in Write Barrier. This fix simmilar to RISC-V one dotnet#90036 * [ARM64] Move GCShadow vars to the end of the wbs block * Update src/coreclr/vm/arm64/asmhelpers.asm --------- Co-authored-by: Jan Kotas <jkotas@microsoft.com>
Co-authored-by: pavelsavara <pavel.savara@gmail.com>
* Remove winternl.h * Remove winver.h * Remove verrsrc.h * Remove dbghelp.h * Remove conio.h * Remove io.h * FILECFAbsoluteTimeToFileTime * Delete some unused header files * More unused structs and macros * Update fxver.h
This reverts commit 27d244b.
Adds a default configuration that comes with all the dependencies preinstalled, but not prebuilt. This reduces confusion if you don't use the "New with options..." dropdown when creating the Codespace since you'd just get a standard Ubuntu container then. Also install a specific version of dotnet-serve.
* Introduce a switch to use FullOpts for cctors * Remove the obsolete policy around cctors * Revert changes around the new switch
…quals` (dotnet#91461) * Add missing comparisons * Add unit tests
* workloads: Skip updating the targeting pack This is required because the runtime pack is still 8.0, but updating the targeting pack from the local build would make it 9.0, thus causing this error for non-wasm apps: ``` Unhandled exception. System.IO.FileNotFoundException: Could not load file or assembly 'System.Runtime, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified. File name: 'System.Runtime, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' ``` * [wasm] makefile cleanup * [wasm] Enable non-wasm build tests
Uses the code sharing infra added in 24e5bce. This shares most of the logic that was easily shareable in the `TestCasesRunner` directory.
…et#91300) Fix a long standing TODO. Formatting of assertion failures and fail-fasts in native AOT matches regular CoreCLR with this change. ```csharp Debug.Assert(false, "Something is not right."); ``` Before: ``` Unhandled Exception: System.Diagnostics.DebugProvider+DebugAssertException: Something is not right. at System.Diagnostics.DebugProvider.Fail(String, String) + 0x49 at System.Diagnostics.Debug.Fail(String, String) + 0x5a at System.Diagnostics.Debug.Assert(Boolean, String, String) + 0x2d at System.Diagnostics.Debug.Assert(Boolean, String) + 0x28 at Program.<Main>$(String[] args) + 0x1d at test!<BaseAddress>+0x1d3a67 at test!<BaseAddress>+0x1d3af5 ``` After: ``` Process terminated. Assertion failed. Something is not right. at System.Diagnostics.DebugProvider.Fail(String, String) + 0x49 at System.Diagnostics.Debug.Fail(String, String) + 0x5a at System.Diagnostics.Debug.Assert(Boolean, String, String) + 0x2d at System.Diagnostics.Debug.Assert(Boolean, String) + 0x28 at Program.<Main>$(String[] args) + 0x1d at repro!<BaseAddress>+0x1d51c7 at repro!<BaseAddress>+0x1d5255 ``` ```csharp Environment.FailFast("Fatal error!"); ``` Before: ``` Process terminated. Fatal error! ``` After: ``` Process terminated. Fatal error! at System.RuntimeExceptionHelpers.FailFast(String, Exception, String, RhFailFastReason, IntPtr, IntPtr) + 0x335 at System.Environment.FailFast(String) + 0x35 at Program.<Main>$(String[] args) + 0x1b at repro!<BaseAddress>+0x1d40c7 at repro!<BaseAddress>+0x1d4155 ```
…st/Runtime packages (dotnet#91031)
* [RISC-V] Generate profiling function callbacks Initial implementation based on ARM64 code. * [RISC-V] Fix asm stub for calling profiler callbacks * Fix argument registers according to RISC-V calling convention * Fix field offsets for PROFILE_PLATFORM_SPECIFIC_DATA * Make sure field offsets for PROFILE_PLATFORM_SPECIFIC_DATA stay fixed by static asserting the offsets in asmconstants.h * [RISC-V] Pass arguments for Profile(Enter|Leave|Tailcall)Naked stubs in t0 and t1 because t2 is used to store the call address of the stub * [RISC-V] Remove unimplemented definition of EmitRet * [RISC-V] Copy struct from registers into a buffer so that profiler can see whole struct arguments laid out in memory * [RISC-V] Implement ProfileArgIterator::GetReturnBufferAddr() Since the RISC-V ABI says values are returned like the first named argument, re-use the struct copying routine from argument parsing as much as possible. * Factor out duplicated test results checking routine in SlowPathELTProfiler::Shutdown() * [RISC-V] Clean up PROFILE_PLATFORM_SPECIFIC_DATA * Remove unused t0 field * Remove 'unused' field and widen 'flags' to 64 bits to maintain alignment and shave off one sw instruction * [RISC-V] Remove commented out code * [RISC-V] Fix formatting * [RISC-V] Apply format patch from failed check * [RISC-V] Post-review fixes
Fixes dotnet#91249 We originally fixed the warnings with dotnet#69236 but due to `add_compile_options()` calls in zlib.cmake _all_ of the mono native libs - not just the zlib components - were being built with C4244 disabled and a few couple more leaked in. This fixes the occurrences and reworks the .cmake files a bit to hopefully prevent this in the future.
…ject that is built outside of test runs (dotnet#91477) - Make a installer/tests/Assets/Projects directory that configures projects to build using the live targeting packs - Move `AppWithSubDirs` under this directory - Put test output under `artifacts/tests/host/<os>.<arch>.<config>` instead of `artifacts/tests/<config>` (better aligned with coreclr test output structure) - Add a `host.pretest` subset for test assets needed for host tests - Currently it just builds the one test asset project, but the intention is that more projects can be moved such that they are built outside of test runs. Setting up the shared framework directory could also be part of this. - Add `SingleFileTestApp` helper that uses output from built test asset projects: - Lays out a directory for the non-bundled app - Creates bundles based on that directory and the (live) shared framework - This should better model the product construction than existing tests, which bundle the entire self-contained output directory (so it has all the native host/runtime files that wouldn't be part of single-file) - I had played with merging this with `TestApp` or reusing `TestApp.Populate*`, but this was special enough (files not on disk, only assemblies) that it seemed more confusing to try to share a code path. - Update `BundledAppWithSubDirs` to use this new mechanism for creating a single-file test app instead of copying/publishing projects - On my Windows machine running on Release everything, these go from a bit over a minute to 12 seconds
On some failure paths, it was boxing a char or an int that would have been used as part of creating an exception on a Parse path but that's ignored on a TryParse path. This avoids that boxing by storing those values into a dedicated int field on the DateTimeResult. While doing this, I also consolidated several other fields, such that this not only avoids the boxing, it also results in a net reduction of the size of DateTimeResult (it's passed around by ref, so this only slightly reduces a zeroing burden).
Fixes dotnet#91309. NativeAOT sources stack trace data from two places: reflection metadata (if the method was reflection-visible), or specialized stack trace metadata. Finding out if a method should be hidden from stack traces in the former case is easy: just look for the attribute. The latter case requires compiler work. In this PR, I'm extending the specialized stack trace metadata format to contain a bit that says if the frame should be hidden or not. I'm doing it in a way that we can also do this for compiler-generated methods (that otherwise don't show up in stack trace metadata). The runtime behavior is similar to CoreCLR - the methods show up in individual stack frames, but if we stringify the stack trace, they'll be skipped. I'm adding a specialized test that tests the two sources of metadata. I'm also marking the methods involved in the startup path as stack trace hidden. There is one thing I skipped - CoreCLR has logic to force generate the stack trace metadata for the first frame. If we do that, the compiler-generated startup code starts showing up in stack traces again. Marking `Main` as stack trace hidden might lead to an empty stack trace.
cpufeatures.h/.c uses TARGET_ ifdefs, but it should use HOST_ ifdefs
This reverts commit 27d244b.
…time into arm64-vector2-intrinsics
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds basic SIMD support for
System.Numerics.Vector2on arm64. Equaling the current support present forSystem.Numerics.Vector4.Current SIMD support for
Vector2with mini/llvm:Vector2/floatscenario, will enable in the next PR)Future work on the missing intrinsic is tracked here #91394.
Contributes to: #73462
p.s. These getters currently use 128-bit code paths for emitting const values (
emit_xconst_v128) even for Vector2 (64-bit vector):While it looks like the generated code is okay locally, it could potentially cause problems in
mono_arch_emit_exceptionsor in subsequent exception handlingruntime/src/mono/mono/mini/mini-arm64.c
Lines 6092 to 6094 in c12429a
@fanyang-mono @jandupej Any thoughts on that? Is dedicated 64-bit const value emit worth implementing?