Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Selective AArch32 Support? #16

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

weliveindetail
Copy link
Collaborator

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:

  1. Target-agnostic passes, like Arithmetic, that already work
  2. Passes with hardcoded inline assembly, like CFG Flattening, can be fixed individually
  3. JIT-based passes, like String Encoding, that require multi-target support in the JIT

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.

…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
@romainthomas
Copy link
Member

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.

Copy link
Collaborator

@antoniofrighetto antoniofrighetto left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Preliminary support looks good to me. Inline assembly to be extended, no concerns on having this opensource.

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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants