[do-not-merge] ARM64_32 changes - #5418
Closed
lewurm wants to merge 10 commits into
Closed
Conversation
Commit list for mono/mono: * mono/mono@fff0b58249b [arm64_32] use emulate OPs so it works with bitcode compiled code for armv7k Diff: mono/mono@8499c4e...fff0b58
lewurm
requested review from
VincentDondain,
chamons,
emaf,
jstedfast,
kzu and
spouliot
as code owners
January 16, 2019 10:48
Contributor
|
Build failure 🔥 Build failed 🔥 |
Contributor
|
You mention both |
spouliot
reviewed
Jan 16, 2019
| } else if (interp) { | ||
| if (fname != "mscorlib.dll") | ||
| throw ErrorHelper.CreateError (99, $"Internal error: can only enable the interpreter for mscorlib.dll when AOT-compiling assemblies (tried to interpret {fname}). Please file an issue at https://github.com/xamarin/xamarin-macios/issues/new."); | ||
| args.Append ("interp,"); |
Contributor
There was a problem hiding this comment.
adding the same value in multiple place makes things harder to understand (and easier to miss when updating).
I think you can have a single if (interp) { args.Append ("interp,"); }
| sw.WriteLine ("\tmono_method_builder_ilgen_init ();"); | ||
| sw.WriteLine ("\tmono_sgen_mono_ilgen_init ();"); | ||
| sw.WriteLine ("\tmono_ee_interp_init (NULL);"); | ||
| sw.WriteLine ("\tmono_jit_set_aot_mode (MONO_AOT_MODE_INTERP_LLVMONLY);"); |
Contributor
There was a problem hiding this comment.
same, too easy to forget to update the (mostly) identical generated code.
Contributor
Author
|
@spouliot my prototype is based on |
Contributor
Member
|
I'll have a look at the required xharness changes. |
Contributor
Author
|
closing in favor of #5465 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Consider this a preview of the changes required to get ARM64_32 going, the architecture introduced with the Watch Series 4. This approach uses the armv7k AOT compiler, and then links the runtime built for arm64_32. This works because the AOT compiler emits bitcode and the ABI of armv7k and arm64_32 are "offset compatible". The caveat is that it only works for the Release mode, but that should be enough to unblock us for the March 2019 deadline.
I'm planning to land the relevant mono changes in
2018-10(see https://github.com/lewurm/mono/commits/2018-08-watch4). For the changes on thexamarin-macios, I'll cherry-pick some of them tomasterand some I'll open against themono-2018-10integration branch. The changes inbuild/Makefilewill need some more polishing. The xharness changes are quite a hack, it should rather be a different platform target (similar to target32/target64 on iOS), but I didn't get that to work.Context: mono/mono#10641
Edit: "pics or it didn't happen"