Build the legacy jit for x86. #2214
Conversation
|
See @BruceForstall 's comment in #1210 . Has that situation changed? |
|
I will give a quick answer. Bruce and others can add to it, or correct it as they see fit. His comment has not changed, the legacy jit is not supported and to my knowledge will not be. Instead, the value it has for us is the ability to use it as a fallback jit to bring up x86. This change allows the legacy jit to act as the default jit and the separate RyuJit dll to be an altjit. |
| add_definitions(-DFEATURE_REF_ZERO_OFFSET_ALLOWED) | ||
|
|
||
| # We will need to build ryujit as an altjit for targets we | ||
| # will be bringing up the jit in. |
There was a problem hiding this comment.
I do not understand how this comment relates to the ifdef you have added
There was a problem hiding this comment.
The ryujit .dll packaged into RyuJIT nuget package should always be the proper RyuJIT, otherwise it will be source of endless confusion. If you would like to do mixing and matching for CoreRT, it should be done by forwarding JIT .dll that implements the multiplexing policy. @russellhadley was talking about having one for mixing and matching ryujit and llilc.
There is nuance in the definition of "supported": it means that Microsoft does not plan to ship it in a officially supported product, but it will likely work reasonably well for foreseeable future - because of it will be used as fallback path for bring up of the proper ryujit backends. cc @cmckinsey |
|
@benpye We intend to keep the LEGACY_BACKEND x86 and ARM32 code-generation paths online in the code base and at the current functionality level until such time when can replace them with a roughly equivalent code-generator based on the new RyuJIT path. For x64 and ARM64 development we will only accept changes that extend the new RyuJIT backend path. Here's my guidance on how non-MS contributors should think about contributing to the JIT: If you want to help advance the state of the production code-generators for .NET, then contribute to the new RyuJIT x86/ARM32 backend. This is our long term direction. If instead your interest is around getting the .NET Core runtime working on x86 or ARM32 platforms to do other things, by all means use and contribute bug fixes if necessary to the LEGACY_BACKEND paths in the RyuJIT code base today to unblock yourself. We do run testing on these paths today in our internal testing infrastructure and will do our best to avoid regressing it until we can replace it with something better. We just want to make sure that there will be no surprises or hard feelings for when the time comes to remove them from the code-base. |
|
Added a link to this JIT porting guidance to the contributing guidelines so that it isn't lost. This should be actually merged into the document at some point. |
In case you don't know yet: you need to add stackfp.cpp and codegenlegacy.cpp to ARCH_SOURCES to get the x86 legacy JIT to build. |
|
Thank you for that information, I did not know that and was looking for it. |
|
Would the Ryujit32 bring-up involve supporting it on Linux as well? |
|
@borgdylan Linux x86 support needs more than a x86 JIT compiler. And even the JIT might need some adjustments to work properly on Linux x86. |
|
@mikedn I never questioned the fact hat a CLR has many moving parts ie. not just the JIT. What I wanted to know whether Linux x86 was on the near future road-map for CoreCLR. |
The JIT should not need any significant adjustments (except for fixing build breaks). We should use the same custom managed x86 calling convention on Linux as is used on Windows. It was done for Silverlight on Mac x86 - it worked pretty well, the code that made it work is still there (e.g. https://github.com/dotnet/coreclr/blob/master/src/vm/fcall.h#L376). |
It is on the road-map, but there is no set time line for when Microsoft folks may start working on it. We still have quite a bit work left to make Linux/MacOS x64 port great product. @borgdylan I know you have done some work on the Linux x86 port a while ago. Any chance you could send PR with the changes you have so far? I will take any good changes that go towards the Linux x86 port. It does not (and should not) need to be one big PR that makes everything work. |
Hmm, I was mostly thinking about the exception handling. I suppose Silverlight didn't use Windows 32 bit style exception handling on OS X. Or did it? |
|
@jkotas The repo has diverged a lot since then. All the work I did is now useless. |
The managed exception handling on Windows x86 is done via vectored exception handler, not via fs:[0] chains. The x86 JIT does not produce the Windows fs:[0] chains, so the same JITed code works fine on non-Windows x86 too. |
Thanks, I completely forgot that. Now I feel really stupid, especially that I remember that I thought it's really cool that x86 CLR doesn't use fs:[0] chains when I first discovered it. |
jashook
changed the title
| @@ -0,0 +1,46 @@ | |||
| project(ryujit) | |||
There was a problem hiding this comment.
This project name is used by jit/ryujit/standalone. It would be nice to use different name here.
|
@jkotas @BruceForstall @adiaaida @RussKeldorph PTAL. Verified that this successfully produces a statically linked legacy jit which fails 30 tests and protojit.dll to be used as the x86 bring up altjit. |
| @@ -137,3 +139,7 @@ set(CLR_EXPORTED_SYMBOL_FILE ${CLRJIT_EXPORTS_DEF}) | |||
| add_subdirectory(dll) | |||
| add_subdirectory(crossgen) | |||
| add_subdirectory(standalone) | |||
|
|
|||
| if (CLR_CMAKE_PLATFORM_ARCH_I386) | |||
There was a problem hiding this comment.
It would be nice to make these I386 || ARM like you had it in your previous iterations...
|
LGTM otherwise. |
|
@jashook, Thanks for signing the contribution license agreement so quickly! Actual humans will now validate the agreement and then evaluate the PR. |
| @@ -1,5 +1,9 @@ | |||
| project(ClrJit) | |||
|
|
|||
| if(CLR_CMAKE_PLATFORM_ARCH_I386) | |||
There was a problem hiding this comment.
It may be a good idea to add this to jit/crossgen/CMakeLists.txt too so that both runtime and crossgen have the same flavor of the JIT statically linked in.
|
Could you please rebase against current master and squash it into single commit, so that it is ready to merge? |
Small changes to cmake to allow us to build the legacy jit as the fallback jit for both x86 and arm.
|
Done. |
|
👍 |
Build the legacy jit for x86. Commit migrated from dotnet/coreclr@4ab4ce8
Small changes to cmake, which allows us to build the legacy jit as the fallback jit for x86.
**** NOTE ****
This change will break the x86 build. It is not ready to merge until the legacy jit link errors are fixed. However, I would like to put it out for review.
@BruceForstall PTAL
Update: created a new cmakelists file to build a seperate ryujit x86 which can be used as the alt jit with the legacy jit linked statically into coreclr.