[NativeAOT-LLVM]: Outstanding tasks tracking issue

[yowl]

If someone want to contribute to the NativeAOT-LLVM branch, its not obvious what tasks need doing. This issue is a checklist of tasks that can be picked up by whoever is interested. Hopefully this will encourage engagement by providing a list where the difficulty can be marked. The list is in a vague priority list, top items = higher priority, but that's just my own preference and not official. Feel free to pick anything you like.

• Complete RyuJIT compilation. The LLVM compilation is currently in 2 modules, the old IL->LLVM module, and the new RyuJIT IR -> LLVM module. The latter offers the opportunity to take advantage of RyuJit's optimisations.
  In progress RyuJIT IR instructions:

  • CT_INDIRECT [NativeAOT-LLVM]: Initial support for IsVirtualVtable calls #1768
  • GT_INDEX/GT_INDEX_ADDR [NativeAOT-LLVM] For TARGET_WASM do not expand to GT_INDEX_ADDR #1824
  • GT_OBJ/GT_STORE_OBJ [NativeAOT-LLVM] Add support for GT_STORE_OBJ and GT_OBJ #1825
  • GT_NULLCHECK [NativeAOT-LLVM] Add support for GT_NULLCHECK #1871
  • GT_STORE_BLK
  • GT_ARR_LENGTH
  • GT_SUB
  • GT_FIELD_LIST NativeAOT-LLVM: Turn on optimisation in RyuJit module, partial support for FIELD_LIST and lowering promoted fields #2007
  • Other IR op codes that need implementing can be identified by placing a break point at

    runtimelab/src/coreclr/jit/llvm.cpp

    Line 1573 in d30559a

    failFunctionCompilation();

• Complete Helper functions

  • CORINFO_HELP_READYTORUN_GENERIC_HANDLE (and generics in general)
  • CORINFO_HELP_READYTORUN_GENERIC_STATIC_BASE
  • CORINFO_HELP_GVMLOOKUP_FOR_SLOT
  • CORINFO_HELP_READYTORUN_DELEGATE_CTOR Some early discussion in [NativeAOT-LLVM] [Question] CORINFO_HELP_READYTORUN_DELEGATE_CTOR implementation #1870

• Merge latest from main/NativeAOT or at least move forward. Note Introduce detection of generic cycles #1681 (comment)

• Release configuration compilation, i.e. src\tests\build nativeaot Release wasm targetsNonWindows skipnative /p:SmokeTestsOnly=true /p:LibrariesConfiguration=Release and src\tests\run runnativeaottests Release wasm currently fails

• Threads

  • Thread suspension: add GC Polls.
  • Confirm atomics are created, for exmaple, Interlocked.*
  • Update runtime code, e.g. where we have #ifndef FEATURE_WASM_THREADS
  • Shadow stack management needs to be moved to Thread (for stack walking non-current threads) (partially done in [NativeAOT-LLVM] Move thread stack top and bottom from thread locals to thread class #2672, still to do is adding shadow stack top to the transition frame)
  • Library code - update for enabling threads.
  • Anything else not thought of, build intergration.

• Linux build - see [NativeAOT-LLVM] add support for building WASI and browser debug & release on Linux #2605

• Mac build

• Mechanism to allow imports and exports through the WebAssembly Canonical ABI (for more info https://github.com/bytecodealliance/wit-bindgen)

• Wasm Exceptions . Probably have to wait until the RyuJIT compilation is complete as Wasm Exceptions are not compatible with c++ exceptions which are currently produced by the IL->LLVM module

• Remove IL->LLVM module

• Other Smoke tests

[charlesroddie]

Once these tasks are done, what will be the status? Will users be able to compile dotnet coffee for running in browser and interacting via DOM or SkiaSharp or is deployment an additional project?

[yowl]

@charlesroddie For DOM, I hope, and no browser has implemented it yet, so its too early to say for sure, but interface types, and the Canonical ABI should allow c#, together with wit-bindgen to interact with the DOM without Javascript. Using Javascript you can do that now, just as Uno and Blazor do. But this is a compiler not a UI framework, so the various additional problems that frameworks like Uno and Blazor solve, e.g. marshalling strings, are not solved here (but some are solved with interface types and the Canonical ABI).

For Skia, that would be interesting to try now. I did look a while back and SkiaSharp had mono dependencies for it's WebAssembly target, but those may have gone now. There's nothing pending I can think of, or in the todo list above, that would prevent Skia from working now, it's a question of what SkiaSharp's dependencies are.

dotnet publish works now producing standard emscripten boiler plate html pages. You can control that with additional options to emcc via /p:EmccExtraArgs= on the dotnet publish command line.

Edit. I tried this and hit #1830 so we'll need that implemented. Added it to the list.

[yowl]

Skia example, Didn't need #1830 in the end, that was a red herring

https://github.com/yowl/wskia/tree/master

[guylangston]

I would be interested/motivated to help with Linux Build, where is the best place to start?

[yowl]

I would be interested/motivated to help with Linux Build, where is the best place to start?

First get the prerequisites installed so you can install and build the feature/NativeAOT branch. See https://github.com/dotnet/runtimelab/blob/feature/NativeAOT/docs/workflow/building/coreclr/nativeaot.md

Then you can have a read of #1797 which was my attempt at it . I'm not sure I was totally on track with what I did so if you look at my branch then bear that in mind.

[yowl]

Also, for general help, things that aren't related to this, you can try asking for help on gitter as some of us hang out there, depending on time zones etc. https://gitter.im/dotnet/corert