Remove some uses of dynamic from HardwareIntrinsic test code

[snickolls-arm]

This is preventing the AdvSimd tests from running in NativeAOT contexts.

Fixes #118234

@dotnet/arm64-contrib

[dotnet-policy-service]

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

[a74nh]

Do the AOT tests get automatically run in the CI ?

[EgorBo]

Do the AOT tests get automatically run in the CI ?

cc @MichalStrehovsky

@MichalStrehovsky please run any outerloop pipelines here if necessary

[EgorBo]

/azp run runtime-nativeaot-outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[MichalStrehovsky]

@MichalStrehovsky please run any outerloop pipelines here if necessary

You found the right one.

[amanasifkhalid]

I still see some usages of dynamic in Helpers.cs, like in SignExtend<T>(). We may not be using these helpers in any of the AdvSimd tests, so NativeAOT isn't blocked (yet), but could you please remove these as well while you're here?

If the remaining uses look tedious to fix, we can save them for a follow-up.

[snickolls-arm]

I still see some usages of dynamic in Helpers.cs, like in SignExtend<T>(). We may not be using these helpers in any of the AdvSimd tests, so NativeAOT isn't blocked (yet), but could you please remove these as well while you're here?

If the remaining uses look tedious to fix, we can save them for a follow-up.

I'm working on the follow-up at the moment and I discovered another problem while doing so: #94015 (comment)

I'm thinking the best way to keep a correct state is to fix that intrinsic that uses the helper, and then remove dynamic from the helper. As the other way around might involve committing some temporarily incorrect code.

[amanasifkhalid]

I'm working on the follow-up at the moment and I discovered another problem while doing so: #94015 (comment)

Ah, I didn't see that. In that case, let's take this as-is. Thanks for the fix!

[amanasifkhalid]

There are some nativeaot-outerloop failures on non-arm64 platforms. A bunch of tests are flagged as failing on linux-arm, despite the console logs showing they exited successfully. Some baseservices/threading tests are failing with OOMs, ex:

17:55:50.857 Running test: baseservices/threading/generics/threadstart/GThread01_threadstart/GThread01_threadstart.dll
System.OutOfMemoryException: Insufficient memory to continue the execution of the program.
   at System.Threading.Thread.StartCore() + 0xd5
   at Gen`1.ThreadPoolTest() + 0xdd
   at Test_thread01.TestEntryPoint() + 0xc3
   at Program.<<Main>$>g__TestExecutor4|0_5(StreamWriter tempLogSw, StreamWriter statsCsvSw, Program.<>c__DisplayClass0_0&) + 0x16f

And on osx-x64, System.Runtime.Numerics.Tests build is failing with the following errors from ILC:

2025-08-01T15:27:58.5531970Z EXEC : error : unexpected line op length at offset 0x00078652 expected 0x2c02 found 0x03 [/Users/runner/work/1/s/src/libraries/System.Runtime.Numerics/tests/System.Runtime.Numerics.Tests.csproj]
2025-08-01T15:27:58.5540700Z EXEC : error : last sequence in debug line table at offset 0x00000000 is not terminated [/Users/runner/work/1/s/src/libraries/System.Runtime.Numerics/tests/System.Runtime.Numerics.Tests.csproj]
2025-08-01T15:27:58.5548600Z EXEC : error : unexpected line op length at offset 0x00078652 expected 0x2c02 found 0x03 [/Users/runner/work/1/s/src/libraries/System.Runtime.Numerics/tests/System.Runtime.Numerics.Tests.csproj]
2025-08-01T15:27:58.5553220Z EXEC : error : last sequence in debug line table at offset 0x00000000 is not terminated [/Users/runner/work/1/s/src/libraries/System.Runtime.Numerics/tests/System.Runtime.Numerics.Tests.csproj]

@MichalStrehovsky do any of these failures look familiar to you?

[MichalStrehovsky]

And on osx-x64, System.Runtime.Numerics.Tests build is failing with the following errors from ILC:

This one is known and Build Analysis correctly paired it.

Some baseservices/threading tests are failing with OOMs, ex:

I've not seen this but Helix machines running into OOM is not unusual. Definitely not related to this PR, I'd not block on it.

[amanasifkhalid]

/ba-g unrelated OOMs