bjorn3 commented on issue #1041:
Rustc_codegen_cranelift has solved this by wrapping inline assembly with a prologue and epilogue and the passing it to an external assembler. It can then be called as regular function from the Cranelift side.
stevefan1999-personal commented on issue #1041:
I'm also very much in need for this. I'm using Cranelift as a backend for my C compiler project. The lack of an assembler is quite unfortunate, which means I have to consider hacking a bit to either bypass Cranelift on assembly/raw/naked functions, or I have to write my own codegen using dynasm.
cfallin commented on issue #1041:
@stevefan1999-personal you or anyone else interested is welcome to contribute! As outlined by sunfishcode above, this is a big design question, so any effort should probably start with an RFC; and then the implementation effort would probably be 3-6 months of fulltime work, I would estimate. Currently none of the core developers have the time/resources to build this, so it would likely have to come from a motivated contributor.
stevefan1999-personal commented on issue #1041:
@cfallin Looks like we should better off moving this into a GH discussion...rather than an issue
cfallin commented on issue #1041:
@stevefan1999-personal we don't use the GitHub Discussions feature here; this issue is perfectly fine for now, I think!
stevefan1999-personal commented on issue #1041:
@stevefan1999-personal we don't use the GitHub Discussions feature here; this issue is perfectly fine for now, I think!
Sure. I just read how Cland and LLVM handles inline assembly and I find it maybe useful towards the end goal:
https://youtu.be/MeB7Dp3G2UE?si=2boJuSqM-JLH2f7o&t=510
Basically, LLVM is also treating the inline assembly as string, replace the parameters, captures used registers and feed it to the register allocator, and then insert the output assembly at the specific point. I'm not sure if I missed something.
cfallin commented on issue #1041:
Basically, LLVM is also treating the inline assembly as string, replace the parameters, captures used registers and feed it to the register allocator, and then insert the output assembly at the specific point. I'm not sure if I missed something.
Indeed, it sounds kind of simple when described at a high level like that. I'd recommend reading sunfishcode's comment above (and really, this whole thread): there are a huge number of complexities here that need to be fully appreciated and handled in any robust solution.
As one example, we currently generate machine code directly, rather than using any existing assembler at the backend. And our machine-code representation is close but not exactly 1-to-1 with instructions, and we don't have representations for instructions we don't use. So at the very least, such a project would require (i) writing a new textual assembler that uses our emission backend, or adopting an existing assembler library in Rust to work with our backend and provide the same interface and metadata to the register allocator, and (ii) extending our instruction representation to support all known CPU instructions. That's an enormous effort.
To state it more explicitly: the input that is most needed here is not ideas or brainstorming or problem-solving, nor confirmation that this is a useful feature; we have plenty of ideas, and we know this is a useful feature that some people want. The input that is needed is human time to actually develop the feature; something like 3-6 months of fulltime engineering. Cranelift is developed by folks who use it for various applications, and we're all quite busy, and don't have the free time for that. Anyone who does, and is sufficiently motivated to need this feature, is welcome to help out!
bjorn3 commented on issue #1041:
In rustc_codegen_cranelift I have a bunch of code which wraps inline asm in a function which uses the SystemV calling convention and then pass this whole asm block to an external assembler. This may or may not work for your use case: https://github.com/bjorn3/rustc_codegen_cranelift/blob/master/src/inline_asm.rs
Last updated: Nov 22 2024 at 16:03 UTC