Adding vectorized implementations of Log2 to Vector64/128/256/512 #96455

tannergooding · 2024-01-03T18:35:01Z

This makes progress towards #93513 and sets up the basic infrastructure for testing the new APIs.

In general the tests are following the same logic as the scalar versions and testing the same values, for simplicity.

The algorithm is the same as being used for the TensorPrimitives type but isn't currently shared due to that being out of band and therefore not supporting the ISimdVector interface since it needs to multi-target $(NetCoreAppPrevious). It's likely not worth the additional #ifdef at this time to have $(NetCoreAppCurrent) calling the APIs exposed on the vector types.

dotnet-issue-labeler · 2024-01-03T18:35:10Z

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.

ghost · 2024-01-03T18:35:16Z

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

Issue Details

This makes progress towards #93513 and sets up the basic infrastructure for testing the new APIs.

In general the tests are following the same logic as the scalar versions and testing the same values, for simplicity.

The algorithm is the same as being used for the TensorPrimitives type but isn't currently shared due to that being out of band and therefore not supporting the ISimdVector interface since it needs to multi-target $(NetCoreAppPrevious). It's likely not worth the additional #ifdef at this time to have $(NetCoreAppCurrent) calling the APIs exposed on the vector types.

Author:	tannergooding
Assignees:	tannergooding
Labels:	`area-System.Numerics`, `new-api-needs-documentation`
Milestone:	-

stephentoub · 2024-01-03T18:48:53Z

The algorithm is the same as being used for the TensorPrimitives type but isn't currently shared due to that being out of band

Presumably we should we be adding a net9.0 TFM to that package and specializing the implementation for net9.0 to use these Vector64/128/256/512 APIs, right?

tannergooding · 2024-01-03T18:56:31Z

Presumably we should we be adding a net9.0 TFM to that package and specializing the implementation for net9.0 to use these Vector64/128/256/512 APIs, right?

We have that currently, it's what $(NetCoreAppCurrent) is targeting. We certainly could consume these APIs, but it's going to involve additional ifdefs in many of the algorithms and it's not clear if that's worth it since we need to duplicate the logic regardless currently.

No strong preference and happy to leave it as is or update it to:

public static Vector128<T> Invoke(Vector128<T> x)
{
#if NET9_0_OR_GREATER
    if (typeof(T) == typeof(double))
    {
        return Vector128.Log2(x.AsDouble()).As<double, T>();
    }
    else
    {
        Debug.Assert(typeof(T) == typeof(float));
        return Vector128.Log2(x.AsSingle()).As<float, T>();
    }
#else
    if (typeof(T) == typeof(double))
    {
        return Log2OperatorDouble.Invoke(x.AsDouble()).As<double, T>();
    }
    else
    {
        Debug.Assert(typeof(T) == typeof(float));
        return Log2OperatorSingle.Invoke(x.AsSingle()).As<float, T>();
    }
#endif
}

stephentoub · 2024-01-03T19:08:39Z

No strong preference and happy to leave it as is or update it to:

Thanks. I'd prefer to use the new APIs when targeting .NET 9, in order to a) help validate them (all of the TensorPrimitives tests will accrue to the Vector APIs), b) benefit from any improvements that might be possible in those core APIs because they're lower in the stack, c) be able to better keep the implementations in sync between what's in TensorPrimitives for .NET 8 and what's in these Vector APIs for 9, and d) reduce the binary size a bit for the library deployed for .NET 9. Eventually, when we no longer need to build for <= .NET 8, we could also remove the custom implementations.

This could also be our answer to #96452 if that's desirable, e.g. these would only be accelerated for .NET 9.

...ries/System.Numerics.Tensors/src/System/Numerics/Tensors/netcore/TensorPrimitives.netcore.cs

tannergooding · 2024-01-03T20:20:25Z

One of the failures is a JIT assert:

Assert failure(PID 10027 [0x0000272b], Thread: 85988 [0x14fe4]): Assertion failed '!m_inited' in 'System.Runtime.Intrinsics.VectorMath:Log2Single[System.Runtime.Intrinsics.Vector128`1[float],System.Runtime.Intrinsics.Vector128`1[int],System.Runtime.Intrinsics.Vector128`1[uint]](System.Runtime.Intrinsics.Vector128`1[float]):System.Runtime.Intrinsics.Vector128`1[float]' during 'Importation' (IL size 976; hash 0xefb066b7; Tier0)

…T 9+

stephentoub · 2024-01-06T01:24:26Z

...ries/System.Numerics.Tensors/src/System/Numerics/Tensors/netcore/TensorPrimitives.netcore.cs

+            }
+        }
+
+#if !NET9_0_OR_GREATER


Is the test project set up to run tests against .NET 8, or are we only testing the .NET 9 and netstandard2.0 bits right now? Given the non-trivial code differences involved in all three versions, it'd probably be best if we ran all three sets of tests... I think right now we're only running two, at least locally (maybe somehow CI runs all of them?)

I'm unsure about which it runs currently. I agree it'd be beneficial if all are running, even if some are in the outer loop.

@ericstj, @ViktorHofer, I understand from Viktor that this is currently not possible. We're going to have a large amount of code in this library that differs between its netstandard, net8, and net9 assets, and really need to run the tests on all three. How can we make that happen in some form?

Steve and I had a conversation about this offline. Being able to test previous .NETCoreApp versions is tracked via #54639.

here are couple things that would need to change:
Obviously, all referenced projects / packages need to support that older .NETCoreApp TFM. I.e. RemoteExecutor currently doesn't (for no particular reason). I have a PR open that changes that: Update Arcade TFMs according to TFM docs by ViktorHofer · Pull Request #14332 · dotnet/arcade (github.com). TestUtilities.csproj in runtime needs to change as well.
Unfortunately, when testing .NETCoreApp our runtime specific test infra relies on the runtime being produced live. Changes are needed in the RunTests scripts and the msbuild tests files.
If you want to have those tests run in CI as well, changes to sendtohelix projects would be required as they have the same "Current" expectations hardcoded.

FWIW there are currently two severe issues affecting running tests locally in runtime:
Local running of libraries tests is broken · Issue #95762 · dotnet/runtime (github.com)
dotnet test is not running tests for .NETFramework targets · Issue #94183 · dotnet/runtime (github.com)

A workaround might be to have a separate test project that uses the net8.0 build of this assembly src project, but it would be running on latest runtime since that's what our tests do. The work to run on older frameworks is substantial as @ViktorHofer points out.

A workaround

Thanks, I'll try.

tannergooding · 2024-01-10T21:38:30Z

src/libraries/System.Collections.Specialized/tests/System.Collections.Specialized.Tests.csproj

+  <PropertyGroup>
+    <!-- Workaround an OOM in LLVM -->
+    <WasmDedup>false</WasmDedup>
+  </PropertyGroup>


@vargaz, could I get sign-off on the workaround here. Same one as you recommended on the other issue.

Looks ok to me, still not sure why that test suite is affected though.

I'm not sure either. But it's not reproing elsewhere and is otherwise blocking the PR.

@vargaz, looks like it's getting a slightly different error now and still hitting an OOM later:

C:\helix\work\correlation\build\wasm-shared\WasmApp.Common.targets(819,5): error : Failed to compile C:\helix\work\workitem\e\wasm_build\obj\wasm\for-build\System.Private.CoreLib.dll.bc -> C:\helix\work\workitem\e\wasm_build\obj\wasm\for-build\System.Private.CoreLib.dll.o [C:\helix\work\workitem\e\publish\ProxyProjectForAOTOnHelix.proj] C:\helix\work\correlation\build\wasm-shared\WasmApp.Common.targets(819,5): error : C:\helix\work\workitem\e\publish>C:\Windows\System32\chcp.com 65001 1>nul [C:\helix\work\workitem\e\publish\ProxyProjectForAOTOnHelix.proj] C:\helix\work\correlation\build\wasm-shared\WasmApp.Common.targets(819,5): error : C:\helix\work\workitem\e\publish>setlocal [C:\helix\work\workitem\e\publish\ProxyProjectForAOTOnHelix.proj] C:\helix\work\correlation\build\wasm-shared\WasmApp.Common.targets(819,5): error : C:\helix\work\workitem\e\publish>set errorlevel=dummy [C:\helix\work\workitem\e\publish\ProxyProjectForAOTOnHelix.proj] C:\helix\work\correlation\build\wasm-shared\WasmApp.Common.targets(819,5): error : C:\helix\work\workitem\e\publish>set errorlevel= [C:\helix\work\workitem\e\publish\ProxyProjectForAOTOnHelix.proj] C:\helix\work\correlation\build\wasm-shared\WasmApp.Common.targets(819,5): error : C:\helix\work\workitem\e\publish>C:\helix\work\correlation\build\\wasi-sdk\\bin\clang.exe "@C:\helix\work\correlation\build\microsoft.netcore.app.runtime.wasi-wasm\runtimes\wasi-wasm\native\src\wasi-default.rsp" "@C:\helix\work\workitem\e\wasm_build\obj\wasm\for-build\wasi-compile-bc.rsp" -c -o "C:\Users\ContainerAdministrator\AppData\Local\Temp\tmp4k2wwb.tmp" "C:\helix\work\workitem\e\wasm_build\obj\wasm\for-build\System.Private.CoreLib.dll.bc" [C:\helix\work\workitem\e\publish\ProxyProjectForAOTOnHelix.proj] C:\helix\work\correlation\build\wasm-shared\WasmApp.Common.targets(819,5): error : clang version 16.0.0 [C:\helix\work\workitem\e\publish\ProxyProjectForAOTOnHelix.proj] C:\helix\work\correlation\build\wasm-shared\WasmApp.Common.targets(819,5): error : Target: wasm32-unknown-wasi [C:\helix\work\workitem\e\publish\ProxyProjectForAOTOnHelix.proj] C:\helix\work\correlation\build\wasm-shared\WasmApp.Common.targets(819,5): error : Thread model: posix [C:\helix\work\workitem\e\publish\ProxyProjectForAOTOnHelix.proj] C:\helix\work\correlation\build\wasm-shared\WasmApp.Common.targets(819,5): error : InstalledDir: C:/helix/work/correlation/build//wasi-sdk//bin [C:\helix\work\workitem\e\publish\ProxyProjectForAOTOnHelix.proj] C:\helix\work\correlation\build\wasm-shared\WasmApp.Common.targets(819,5): error : (in-process) [C:\helix\work\workitem\e\publish\ProxyProjectForAOTOnHelix.proj] C:\helix\work\correlation\build\wasm-shared\WasmApp.Common.targets(819,5): error : "C:/helix/work/correlation/build/wasi-sdk/bin/clang.exe" -cc1 -triple wasm32-unknown-wasi -emit-obj -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name System.Private.CoreLib.dll.bc -mrelocation-model static -mframe-pointer=none -ffp-contract=on -fno-rounding-math -mconstructor-aliases -target-cpu generic -fvisibility=hidden -mllvm -treat-scalable-fixed-error-as-warning -debug-info-kind=constructor -dwarf-version=4 -debugger-tuning=gdb -v -fcoverage-compilation-dir=C:/helix/work/workitem/e/publish -resource-dir C:/helix/work/correlation/build/wasi-sdk/lib/clang/16 -Oz -fdebug-compilation-dir=C:/helix/work/workitem/e/publish -ferror-limit 19 -fgnuc-version=4.2.1 -vectorize-slp -o "C:\\Users\\ContainerAdministrator\\AppData\\Local\\Temp\\tmp4k2wwb.tmp" -x ir "C:\\helix\\work\\workitem\\e\\wasm_build\\obj\\wasm\\for-build\\System.Private.CoreLib.dll.bc" [C:\helix\work\workitem\e\publish\ProxyProjectForAOTOnHelix.proj] C:\helix\work\correlation\build\wasm-shared\WasmApp.Common.targets(819,5): error : clang -cc1 version 16.0.0 based upon LLVM 16.0.0 default target wasm32-wasi [C:\helix\work\workitem\e\publish\ProxyProjectForAOTOnHelix.proj] C:\helix\work\correlation\build\wasm-shared\WasmApp.Common.targets(819,5): error : LLVM ERROR: out of memory [C:\helix\work\workitem\e\publish\ProxyProjectForAOTOnHelix.proj] C:\helix\work\correlation\build\wasm-shared\WasmApp.Common.targets(819,5): error : Allocation failed [C:\helix\work\workitem\e\publish\ProxyProjectForAOTOnHelix.proj] C:\helix\work\correlation\build\wasm-shared\WasmApp.Common.targets(819,5): error : PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script. [C:\helix\work\workitem\e\publish\ProxyProjectForAOTOnHelix.proj] C:\helix\work\correlation\build\wasm-shared\WasmApp.Common.targets(819,5): error : Stack dump: [C:\helix\work\workitem\e\publish\ProxyProjectForAOTOnHelix.proj] C:\helix\work\correlation\build\wasm-shared\WasmApp.Common.targets(819,5): error : 0. Program arguments: C:\\helix\\work\\correlation\\build\\\\wasi-sdk\\\\bin\\clang.exe @C:\\helix\\work\\correlation\\build\\microsoft.netcore.app.runtime.wasi-wasm\\runtimes\\wasi-wasm\\native\\src\\wasi-default.rsp @C:\\helix\\work\\workitem\\e\\wasm_build\\obj\\wasm\\for-build\\wasi-compile-bc.rsp -c -o C:\\Users\\ContainerAdministrator\\AppData\\Local\\Temp\\tmp4k2wwb.tmp C:\\helix\\work\\workitem\\e\\wasm_build\\obj\\wasm\\for-build\\System.Private.CoreLib.dll.bc [C:\helix\work\workitem\e\publish\ProxyProjectForAOTOnHelix.proj] C:\helix\work\correlation\build\wasm-shared\WasmApp.Common.targets(819,5): error : 1. Code generation [C:\helix\work\workitem\e\publish\ProxyProjectForAOTOnHelix.proj] C:\helix\work\correlation\build\wasm-shared\WasmApp.Common.targets(819,5): error : 2. Running pass 'Function Pass Manager' on module 'C:\helix\work\workitem\e\wasm_build\obj\wasm\for-build\System.Private.CoreLib.dll.bc'. [C:\helix\work\workitem\e\publish\ProxyProjectForAOTOnHelix.proj] C:\helix\work\correlation\build\wasm-shared\WasmApp.Common.targets(819,5): error : 3. Running pass 'WebAssembly Explicit Locals' on function '@corlib_System_Buffers_IndexOfAnyAsciiSearcher_IndexOfAnyVectorized_System_Buffers_IndexOfAnyAsciiSearcher_DontNegate_System_Buffers_IndexOfAnyAsciiSearcher_Default_int16__int_System_Buffers_IndexOfAnyAsciiSearcher_AsciiState_' [C:\helix\work\workitem\e\publish\ProxyProjectForAOTOnHelix.proj] C:\helix\work\correlation\build\wasm-shared\WasmApp.Common.targets(819,5): error : Exception Code: 0xC000001D [C:\helix\work\workitem\e\publish\ProxyProjectForAOTOnHelix.proj] C:\helix\work\correlation\build\wasm-shared\WasmApp.Common.targets(819,5): error : 0x003CFB73 <unknown module> [C:\helix\work\workitem\e\publish\ProxyProjectForAOTOnHelix.proj] C:\helix\work\correlation\build\wasm-shared\WasmApp.Common.targets(819,5): error : 0x71B0C902 <unknown module> [C:\helix\work\workitem\e\publish\ProxyProjectForAOTOnHelix.proj] C:\helix\work\correlation\build\wasm-shared\WasmApp.Common.targets(819,5): error : 0x003B23A1 <unknown module> [C:\helix\work\workitem\e\publish\ProxyProjectForAOTOnHelix.proj] C:\helix\work\correlation\build\wasm-shared\WasmApp.Common.targets(819,5): error : 0x003B44C0 <unknown module> [C:\helix\work\workitem\e\publish\ProxyProjectForAOTOnHelix.proj] C:\helix\work\correlation\build\wasm-shared\WasmApp.Common.targets(819,5): error : 0x00C72CA9 <unknown module> [C:\helix\work\workitem\e\publish\ProxyProjectForAOTOnHelix.proj] C:\helix\work\correlation\build\wasm-shared\WasmApp.Common.targets(819,5): error : 0x00C72F30 <unknown module> [C:\helix\work\workitem\e\publish\ProxyProjectForAOTOnHelix.proj] C:\helix\work\correlation\build\wasm-shared\WasmApp.Common.targets(819,5): error : 0x00C72E9A <unknown module> [C:\helix\work\workitem\e\publish\ProxyProjectForAOTOnHelix.proj] C:\helix\work\correlation\build\wasm-shared\WasmApp.Common.targets(819,5): error : 0x00C72E2C <unknown module> [C:\helix\work\workitem\e\publish\ProxyProjectForAOTOnHelix.proj] C:\helix\work\correlation\build\wasm-shared\WasmApp.Common.targets(819,5): error : 0x0057829A <unknown module> [C:\helix\work\workitem\e\publish\ProxyProjectForAOTOnHelix.proj] C:\helix\work\correlation\build\wasm-shared\WasmApp.Common.targets(819,5): error : 0x0281BFA0 <unknown module> [C:\helix\work\workitem\e\publish\ProxyProjectForAOTOnHelix.proj] C:\helix\work\correlation\build\wasm-shared\WasmApp.Common.targets(819,5): error : 0x02714C1C <unknown module> [C:\helix\work\workitem\e\publish\ProxyProjectForAOTOnHelix.proj] C:\helix\work\correlation\build\wasm-shared\WasmApp.Common.targets(819,5): error : clang: error: clang frontend command failed due to signal (use -v to see invocation) [C:\helix\work\workitem\e\publish\ProxyProjectForAOTOnHelix.proj] C:\helix\work\correlation\build\wasm-shared\WasmApp.Common.targets(819,5): error : clang version 16.0.0 [C:\helix\work\workitem\e\publish\ProxyProjectForAOTOnHelix.proj] C:\helix\work\correlation\build\wasm-shared\WasmApp.Common.targets(819,5): error : Target: wasm32-unknown-wasi [C:\helix\work\workitem\e\publish\ProxyProjectForAOTOnHelix.proj] C:\helix\work\correlation\build\wasm-shared\WasmApp.Common.targets(819,5): error : Thread model: posix [C:\helix\work\workitem\e\publish\ProxyProjectForAOTOnHelix.proj] C:\helix\work\correlation\build\wasm-shared\WasmApp.Common.targets(819,5): error : InstalledDir: C:/helix/work/correlation/build//wasi-sdk//bin [C:\helix\work\workitem\e\publish\ProxyProjectForAOTOnHelix.proj] C:\helix\work\correlation\build\wasm-shared\WasmApp.Common.targets(819,5): error : clang: note: diagnostic msg: Error generating preprocessed source(s) - no preprocessable inputs. [took 152.83s] [C:\helix\work\workitem\e\publish\ProxyProjectForAOTOnHelix.proj]

vargaz · 2024-01-10T22:36:47Z

/azp run runtime-wasm

azure-pipelines · 2024-01-10T22:37:07Z

Azure Pipelines successfully started running 1 pipeline(s).

vargaz · 2024-01-11T15:22:19Z

One difference between the linked corlib with this PR is now Vector512 is not linked away, which causes a bunch more code to be AOTed. It looks like the problem is actually the methods added to AssertExtensions, those methods are not linked away for some reason, keeping Vector512 alive as well.

…M trimming issues

tannergooding · 2024-01-11T17:36:36Z

It looks like the problem is actually the methods added to AssertExtensions, those methods are not linked away for some reason, keeping Vector512 alive as well.

I've relocated those to only be in System.Runtime.Intrinsics.Tests for the time being, which should hopefully help avoid the issue.

…tnet#96455) * Adding vectorized implementations of Log2 to Vector64/128/256/512 * Accelerate TensorPrimitives.Log2<double>() * Undo a sln file change * Use the built-in Log2 implementation from Vector64/128/256/512 on .NET 9+ * Ensure the helpers are checking the correct types * Relocate the Vector64/128/256/512 assert extensions to avoid Mono LLVM trimming issues * Keep xunit happy

ghost assigned tannergooding Jan 3, 2024

dotnet-issue-labeler bot added area-System.Numerics new-api-needs-documentation labels Jan 3, 2024

stephentoub reviewed Jan 3, 2024

View reviewed changes

...ries/System.Numerics.Tensors/src/System/Numerics/Tensors/netcore/TensorPrimitives.netcore.cs Show resolved Hide resolved

tannergooding mentioned this pull request Jan 3, 2024

JIT assert on Unix in ReturnTypeDesc::InitializeStructReturnType #96461

Closed

This was referenced Jan 3, 2024

[wasi] System.Globalization.Tests AOT build fails with LLVM ERROR: out of memory on Windows #95365

Closed

[libraries-jitstress] Failures in System.Numerics.Tensors.Tests.*Generic* #96464

Closed

tannergooding added 4 commits January 4, 2024 10:00

Adding vectorized implementations of Log2 to Vector64/128/256/512

511e434

Accelerate TensorPrimitives.Log2<double>()

0b9626c

Undo a sln file change

cc01c72

Use the built-in Log2 implementation from Vector64/128/256/512 on .NE…

8ee5bff

…T 9+

tannergooding force-pushed the fix-93513 branch from 4039954 to 8ee5bff Compare January 4, 2024 18:00

build-analysis bot mentioned this pull request Jan 4, 2024

[wasm] Failing test System.Runtime.InteropServices.JavaScript.Tests.WebWorkerTest.ManagedDelay_ContinueWith #96493

Closed

Ensure the helpers are checking the correct types

9cfc7fd

This was referenced Jan 4, 2024

Checkout failure: "Git fetch failed with exit code 128" dotnet/arcade#9009

Open

Test failure - System.NullReferenceException in System.Threading.Lock.TryInitializeStatics #94728

Closed

stephentoub reviewed Jan 6, 2024

View reviewed changes

stephentoub approved these changes Jan 6, 2024

View reviewed changes

tannergooding mentioned this pull request Jan 8, 2024

Hitting OOM in LLVM for the wasi-wasm aot smoke tests #96630

Closed

tannergooding force-pushed the fix-93513 branch from f5cc6c4 to f38bcfa Compare January 8, 2024 17:30

stephentoub mentioned this pull request Jan 8, 2024

Add .NET 8 test project for System.Numerics.Tensors #96641

Merged

tannergooding force-pushed the fix-93513 branch from ca6b731 to 5e9c78f Compare January 10, 2024 19:52

tannergooding commented Jan 10, 2024

View reviewed changes

This was referenced Jan 11, 2024

[wasm][debugger] Debugger tests getting randomly aborted on CI #89409

Open

The active test run was aborted. Reason: Test host process crashed dotnet/dnceng#451

Open

[browser][AOT] wasm-ld : error : initial memory too small #96840

Closed

tannergooding added 2 commits January 11, 2024 09:34

Merge remote-tracking branch 'dotnet/main' into fix-93513

84a25fa

Relocate the Vector64/128/256/512 assert extensions to avoid Mono LLV…

95622ff

…M trimming issues

tannergooding force-pushed the fix-93513 branch from 5e9c78f to 95622ff Compare January 11, 2024 17:35

Keep xunit happy

0218d1d

tannergooding merged commit a3d5261 into dotnet:main Jan 11, 2024
178 checks passed

tannergooding deleted the fix-93513 branch January 11, 2024 21:49

This was referenced Jan 11, 2024

[wasm] AOT: System.Numerics.Tensors.Net8.Tests - aot-instances.dll with exit code 137 #96865

Closed

[wasm] AOT: OOM when compiling System.Numerics.Tensors.Tests.dll #96866

Closed

kotlarmilos mentioned this pull request Jan 17, 2024

[Perf] Linux/x64: 4 Improvements on 1/11/2024 10:37:40 PM dotnet/perf-autofiling-issues#27356

Closed

github-actions bot locked and limited conversation to collaborators Feb 11, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Adding vectorized implementations of Log2 to Vector64/128/256/512 #96455

Adding vectorized implementations of Log2 to Vector64/128/256/512 #96455

tannergooding commented Jan 3, 2024

dotnet-issue-labeler bot commented Jan 3, 2024

ghost commented Jan 3, 2024

stephentoub commented Jan 3, 2024

tannergooding commented Jan 3, 2024

stephentoub commented Jan 3, 2024

tannergooding commented Jan 3, 2024

stephentoub Jan 6, 2024

tannergooding Jan 6, 2024

stephentoub Jan 6, 2024

ViktorHofer Jan 8, 2024

ericstj Jan 8, 2024

stephentoub Jan 8, 2024

stephentoub Jan 8, 2024

tannergooding Jan 10, 2024

vargaz Jan 10, 2024

tannergooding Jan 10, 2024

tannergooding Jan 10, 2024

vargaz commented Jan 10, 2024

azure-pipelines bot commented Jan 10, 2024

vargaz commented Jan 11, 2024

tannergooding commented Jan 11, 2024

Adding vectorized implementations of Log2 to Vector64/128/256/512 #96455

Adding vectorized implementations of Log2 to Vector64/128/256/512 #96455

Conversation

tannergooding commented Jan 3, 2024

dotnet-issue-labeler bot commented Jan 3, 2024

ghost commented Jan 3, 2024

stephentoub commented Jan 3, 2024

tannergooding commented Jan 3, 2024

stephentoub commented Jan 3, 2024

tannergooding commented Jan 3, 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

vargaz commented Jan 10, 2024

azure-pipelines bot commented Jan 10, 2024

vargaz commented Jan 11, 2024

tannergooding commented Jan 11, 2024