NativeAOT: Cover more opcodes in type preinitializer #112073
Conversation
dotnet-policy-service
bot
added
the
community-contribution
hez2010
force-pushed
the
more-interpreter
branch
from
76fd747 to
62e2316
Compare
It doesn't harm, but each of these requires test coverage. We keep our tests here: |
|
I'll be OOF for several days so tests will be added later. But feel free to take it if you would like. |
It can wait. |
MichalStrehovsky
added
the
needs-author-action
dotnet-policy-service
bot
removed
the
needs-author-action
|
@MichalStrehovsky PTAL. |
|
/ba-g wasm failure is already fixed in main #112244 |
|
/azp run runtime-nativeaot-outerloop |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
Hmm the linux-arm failure seems related. Is there anything special on arm32? |
I don't actually know how we define float conversion rules. I'd not be surprised if it's float precision issues. The reasons why this wasn't implemented were twofold: nothing I tried ever needed it (we go for 20% effort, 80% effect), and i didn't have confidence in implementing these. |
|
I added some messages for debug. Can you trigger nativeaot-outerloop again? |
|
/azp run runtime-nativeaot-outerloop |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Seems that we handled the conversion correctly. (I actually checked ECMA-335 for the fix d3b2b0f so this should not be a problem) |
|
Maybe it's the same issue I addressed in 6c63ed8 before, where we also need to handle |
|
/azp run runtime-nativeaot-outerloop |
|
Azure Pipelines successfully started running 1 pipeline(s). |
These legs have been constantly timing out since beginning of January because Helix is overloaded (e.g. #112073). In looking at why we don't see timeouts with CoreCLR, I found out we do not test ARM64 OSX with CoreCLR on all PRs. So this moves it to the same plan as e.g. ARM32 Linux.
|
I just used the alt jit to spot the issue, and it turns out to be: Seems like a cursed test case as I don't plan to support |
|
Test should pass now. |
These legs have been constantly timing out since beginning of January because Helix is overloaded (e.g. #112073). In looking at why we don't see timeouts with CoreCLR, I found out we do not test ARM64 OSX with CoreCLR on all PRs. So this moves it to the same plan as e.g. ARM32 Linux.
|
/azp run runtime-nativeaot-outerloop |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
nativeaot-outerloop is passing. |
* main: [Android] Run CoreCLR functional tests on Android (dotnet#112283) [LoongArch64] Fix some assertion failures for Debug ILC building Debug NativeAOT testcases. (dotnet#112229) Fix suspicious code fragments (dotnet#112384) `__ComObject` doesn't support dynamic interface map (dotnet#112375) Native DLLs: only load imported DLLs from System32 (dotnet#112359) [main] Update dependencies from dotnet/roslyn (dotnet#112314) Update SVE instructions that writes to GC regs (dotnet#112389) Bring up android+coreclr windows build. (dotnet#112256) Never use heap for return buffers (dotnet#112060) Wait to complete the test before releasing the agile reference. (dotnet#112387) Prevent returning disposed HTTP/1.1 connections to the pool (dotnet#112383) Fingerprint dotnet.js if writing import map to html is enabled (dotnet#112407) Remove duplicate definition of CORECLR_HOSTING_API_LINKAGE (dotnet#112096) Update the exception message to reflect current behavior. (dotnet#112355) Use enum for frametype not v table (dotnet#112166) Enable AltJits build for LoongArch64 and RiscV64 (dotnet#110282) Guard members of MonoType union & fix related bugs (dotnet#111645) Add optional hooks for debugging OpenSSL memory allocations (dotnet#111539) JIT: Optimize struct parameter register accesses in the backend (dotnet#110819) NativeAOT: Cover more opcodes in type preinitializer (dotnet#112073)
Some low hanging fruits.
I initially did this to allow preinitializing method call to
Math.*.But it doesn't harm to support all of conv opcodes, so I did for them all.