Skip to content

Target-dependent translation of inline asm #383

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

Merged
merged 20 commits into from
May 3, 2022

Conversation

fw-immunant
Copy link
Contributor

This would benefit greatly from feedback on how it's detecting target architecture, which is currently pretty hacky and completely undocumented, and will also need some consideration on how we can test target-architecture-specific functionality in CI (I want to make sure installing toolchains for multiple architectures doesn't slow down CI as a whole too much, and we need to have a way to validate translation of programs for non-host architectures, perhaps without running them).

@fw-immunant fw-immunant force-pushed the fw/target-dependent-asm branch from fead6b0 to 0eccb6b Compare April 27, 2022 19:38
@fw-immunant
Copy link
Contributor Author

I've fixed a couple more bugs and added tests which will also test other architectures (just arm for now) as much as their runtime environment permits.

@fw-immunant fw-immunant force-pushed the fw/target-dependent-asm branch 4 times, most recently from c2b16ed to 52de819 Compare April 28, 2022 00:43
@fw-immunant fw-immunant marked this pull request as ready for review April 28, 2022 00:57
@fw-immunant fw-immunant changed the title WIP: target-dependent asm Target-dependent translation of inline asm Apr 28, 2022
@fw-immunant fw-immunant linked an issue Apr 28, 2022 that may be closed by this pull request
Copy link
Contributor

@rinon rinon left a comment

Choose a reason for hiding this comment

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

LGTM, but maybe Andrei should take another look because I haven't really looked at inline asm in a while.

asm.contains('$')
// Guess based on sigils used in AT&T assembly. This would be more
// robust if it stripped comments first.
asm.contains('$') || asm.contains('%') || asm.contains('(')
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm a bit concerned that '(' is too broad and will end up with false positives.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

'(' is intended to pick out disp(base,idx,scale) address calculations in AT&T syntax. Is there anywhere it can appear in Intel syntax? The only places I can think of are comments and macros. It's not hard to remove comments, but parsing macros seems like it's more trouble than we should bother with.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We now remove comments before searching for these sigils.

@fw-immunant fw-immunant force-pushed the fw/target-dependent-asm branch from f13b4b4 to 9771113 Compare April 28, 2022 21:29
not doing so could lead to a double-ampersand being emitted, which is not correct

see #382
this is useful on the transpiler side for correctly interpreting inline asm
…isters

for now we don't actually check specific reserved registers for non-x86 architectures, as I was not able to find any documentation listing which registers are reserved
…egister or index

previously, if there were multiple inputs with similar but broad constraints, these would be incorrectly conflated and considered eligible for input-output association
this numbering follows the order used by gcc inline asm, i.e. outputs, inputs, then clobbers
@fw-immunant fw-immunant force-pushed the fw/target-dependent-asm branch 3 times, most recently from b2d06ea to 505fe05 Compare April 29, 2022 22:33
architecture-specific tests are denoted by ending their name with .$arch
(such as .x86_64) and including a "target-tuple" file containing a target
tuple on which the test is known to work.

running tests on a host of the same architecture works as before; if the
architectures differ, the target tuple is used to correctly transpile the
test and (if an appropriate toolchain is present) compile the transpiled
sources as well. lacking this toolchain is not considered a test failure.
remove comments before searching for sigils to determine if asm is AT&T or Intel syntax
support for these was added in Clang/LLVM 11, so this handling is #ifdef'd on that
for one major release, ElementCount's fields were public and not accessed via getters
like Half, this is basically just a stub for now

supporting these types properly could use the `half` crate, but this is just to get basic AArch64 translation working

this type was also added in Clang/LLVM 11, so ifdef'd accordingly

we need to handle these now because ARMv8.6-a adds the BFloat16/__bf16 type as a vector element of one of the SVE vector types just added
@fw-immunant fw-immunant force-pushed the fw/target-dependent-asm branch from 505fe05 to d4278f5 Compare May 2, 2022 14:37
@fw-immunant fw-immunant mentioned this pull request May 2, 2022
@@ -291,6 +498,12 @@ fn rewrite_asm<F: Fn(&str) -> bool>(asm: &str, is_mem_only: F) -> String {
continue;
}

// Note empty chunks
if chunk == "" {
Copy link
Contributor

Choose a reason for hiding this comment

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

Minor nit: chunk.is_empty() could have worked too.

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.

Transpile llvm_asm to asm
3 participants