Selective AArch32 Support? #16
Open
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
…ed passes (1) Arithmetic is target-agnostic and appears to work well already (2) CFG Flattening hardcodes inline assembly and can be fixed easily (3) String Encoding uses the JIT and might be more complicated to port
|
There are also other places where passes depend on the target architecture: For ARM32, there might also be considerations for the thumb mode since the instruction's size can change compared to AArch64. |
sevilS
pushed a commit
that referenced
this pull request
Apr 3, 2024
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.
Support for 32-bit targets would be interesting for Android targets, even though the primary focus for O-MVLL is AArch64. . Please consider this a starting point for a discussion, not more and not less.
When it comes to multi-target support, we can distinguish three types of passes right now:
My first commit adds a minimal test for each of the given examples. Initially only type (1) passes. The others expectedly fail.
My second commit fixes the type (2) test. While the given inline assembly might be bogus, the patch isn't very invasive. The big benefit of the change behind the fix is, that we won't bail out in the compiler backend with a cryptic error message anymore in case of an incompatible triple. Instead, we'd deliberately fail with a reasonable error message right away. This approach doesn't add a ton of complexity. We could just keep iterating. Doing it right might improve the quality of the plugin.
JIT support isn't here yet, but maybe it's not terribly complicated either. Clang and ORC are multi-target ready from the start. And we only need to run the frontend anyway, because we don't aim to run the code generated for the target. We only inject the IR into the existing module.
Please note that this is implemented on-top of #14 (the two first commits) and should be rebased once it landed.