This repo is going to be archived on October 31, 2020

[jkotas]

We are centralizing all experimental projects based on dotnet/runtime in a new https://github.com/dotnet/runtimelab repo. More details about this effort are in dotnet/runtime#35609 .

Runtime optimized for AOT and RyuJIT codegen backend that were the two largest and most mature CoreRT components have been moved to their new place at https://github.com/dotnet/runtimelab/tree/feature/NativeAOT . The engineering infrastructure is setup, the packages are being published to a new NuGet feed and we are ready to start taking contributions. As with any new developer workflow, we know that there will be rough edges. Please help us smooth them out!

CoreRT is dead, long live NativeAOT!

We would like to keep the experiments in dotnet/runtimelab more focused. Let’s use this issue to discuss what else would make sense to move over and in what form. I will be happy to sponsor experiments with significant interest. This includes the wasm target that @yowl has been relentlessly working on.

[jkotas]

The one particular experiment that would be close to my heart is combined RyuJIT frontend and LLVM backend codegen. The discussion at #8230 has more details about what it may look like (look for “long term”). Would it make sense to keep it together with the wasm target (ie it would be RyuJIT + LLVM + wasm)?

[PathogenDavid]

I still think it's a bit odd to have multiple experiments kludged together in the same repo, but I'll take your word for it that it's easier from a engineering perspective. Regardless I'm glad the transition is finally complete!

The one particular experiment that would be close to my heart is combined RyuJIT frontend and LLVM backend codegen.

This definitely sounds interesting. What role does RyuJIT play in this scenario? Does it help solve issues LLILC had with its LLVM-based approach?

[RalfKornmannEnvision]

Is there still interest in PRs for full (native) Android support in NativeAOT? 

[jkotas]

What role does RyuJIT play in this scenario? Does it help solve issues LLILC had with its LLVM-based approach?

The RyuJIT has large number of platform-neutral managed-code specific optimizations that are required for a good code quality. It would be very expensive to redo them for LLVM and to keep up with new ones being added. It was one of the LLILC issues.

The idea is to take these platform-neutral managed-code specific optimizations from RyuJIT and take the (platform-specific) optimizations from LLVM. The LLVM codegen in Mono is done in similar way.

[jkotas]

Is there still interest in PRs for full (native) Android support in NativeAOT?

Yes, absolutely!

CoreCLR has seen some work done on Android too. Any platform where CoreCLR runs (or that is close to one) is a fair game for NativeAOT.

[PathogenDavid]

The RyuJIT has large number of platform-neutral managed-code specific optimizations that are required for a good code quality.

That makes a lot of sense, thanks for the info!

[yowl]

I could create a ILCompiler.LLVM basically pulling out the LLVM target quadruple and layout to parameters. The shadow stack and parameter passing which exist due to Wasm stack scanning limitations, but otherwise are agnostic and wont stop other targets as @christianscheuer demonstrated with the Mac build in #8230, can come out later? I don't know why the reverse pinvoke calls are commented out there, that might be an issue.

Testing it needs a real target I suppose. There is a LLVM interpreter, but that's probably just introducing problems. The HelloWasm tests for the majority are also agnostic, only the Javascript interop test needs Wasm. It's a bit of a mess admittedly, but does cover more than exists in just the Generics and Exceptions tests, so would be an option?

[mrhelmut]

Hooray!

Maybe I missed the info in the documentation, but what is the new nuget feed and package name?

Also, will the previous CoreRT nuget feed be taken down at some point?

Just thought asking to plan the migration accordingly.
Thanks for pushing this project forward! We're really having some results in production from our end.

Cheers!

[jkotas]

The nuget feed is mentioned in samples: https://github.com/dotnet/runtimelab/tree/feature/NativeAOT/samples/HelloWorld#add-corert-to-your-project . The package name is still the same.

will the previous CoreRT nuget feed be taken down at some point?

The old CoreRT nuget feed is part of .NET Core 3.x engineering infrastructure. It will be taken down once .NET Core 3 goes out of support.

We're really having some results in production from our end.

Glad to hear that!

[jkotas]

I could create a ILCompiler.LLVM basically pulling out the LLVM target quadruple and layout to parameters.

Yes, this should work. I think a good experiment branch name for this may be NativeAOT-LLVM. It can start with the LLVM+wasm bits from this repo and it can evolve towards being a more general LLVM-based codegen. @yowl Would you be interested in working on this?

For reference, https://github.com/dotnet/runtimelab/blob/master/CreateAnExperiment.md are steps for setting up a new experiment branch.

[yowl]

Yes, can do. Does it qualify for a branch name of feature/NativeAOT-LLVM ? Do I branch it from dotnet/runtimelab:runtime-master and then merge in feature/NativeAOT or branch directly from feature/NativeAOT ?

[jkotas]

Yep, I have created the branch https://github.com/dotnet/runtimelab/tree/feature/NativeAOT-LLVM - branched from feature/NativeAOT. Feel free to start submitting PRs against it.

[tonerdo]

@jkotas is there a place for the interpreter work in runtimelab? I'm still actively working on it

[jkotas]

We can create another experimental branch for the IL interpreter.

[josephmoresena]

ASP .Net Core won't be a NativeAOT scenery?

[davidfowl]

Yes, it will be