[do-not-merge] ARM64_32 changes #5418
Closed
Conversation
This file contains 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
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
chamons,
emaf,
jstedfast,
kzu,
spouliot and
VincentDondain
as code owners
|
Build failure 🔥 Build failed 🔥 |
|
You mention both |
spouliot
reviewed
Jan 16, 2019
| args.Append ("llvmonly,"); | ||
| else if (interp) { | ||
| } 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,"); |
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);"); |
There was a problem hiding this comment.
same, too easy to forget to update the (mostly) identical generated code.
|
@spouliot my prototype is based on |
|
I'll have a look at the required xharness changes. |
|
closing in favor of #5465 |
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"