Tracking Issue for LLVM-style inline assembly (llvm_asm)

[Amanieu]

This is a tracking issue for the RFC "2843" (rust-lang/rfcs#2843).
The feature gate for the issue is #![feature(llvm_asm)].

This issue tracks the legacy inline assembly macro llvm_asm! which more-or-less maps directly to LLVM's internal representation of inline assembly.

There is currently no plan for stabilizing this macro, but there is a proposal to replace it with the new inline assembly macro specified in RFC 2873 (rust-lang/rfcs#2873).

Implementation PR: #68404

[mark-i-m]

cc #68404

[RalfJung]

The fact that this is a Statement in MIR, and not a Terminator, breaks a bunch of semantic assumptions that one could otherwise make about MIR basic blocks. Even if this feature does not get stabilized, it doesn't seem great to have optimizations that entirely break in the presence of llvm_asm. (I would be very surprised if there isn't a soundness issue here, but don't know about about the area to produce a concrete example.)

Are there plans to either fix that, or else entirely remove legacy inline assembly support?

[Amanieu]

The plan is to deprecate llvm_asm! and eventually remove it. However I am hesitant to remove it immediately since there are still many people relying on it.

I think we should be able to remove it after a deprecation period of a month or two.

[BartMassey]

While I'm not volunteering :-) it would be great if someone implemented a cargo fix to try to rewrite old-style asm!() to new-style automagically. I'm not sure how hard it would be: I feel like it could at least fix some simple cases and warn about the rest…

[nikomatsakis]

@RalfJung can you elaborate a bit about the semantic assumptions you are referring to? I guess the freedom to move code about within a block or something?

Certainly we could make it a terminator, although that seems a bit arbitrary.

[Amanieu]

I believe @RalfJung is referring to things like this.

@BartMassey Unfortunately this is very difficult to do reliably due to the differences between the two syntax. Currently we have an automated cargo fix which will turn old-style asm! to the equivalent llvm_asm!.

[BartMassey]

@Amanieu Yeah, I think solving it completely would be pretty hard, but it would be nice to at least transform the simplest cases (all the arguments in registers, simple read/write/clobbers) and somehow mark/warn about the cases that couldn't be auto-transformed so that people would notice them and fix them.

If llvm_asm!() is going to disappear in months, not years, it seems really important to ease the transition away from it as much as possible.

But like I say, this is a wish list item: if I really cared I'd do it myself 🤷. Thanks again for all the hard work that has gone into this — I'm really looking forward to our sane-syntax assembly future.

[RalfJung]

can you elaborate a bit about the semantic assumptions you are referring to? I guess the freedom to move code about within a block or something?

Things like what @Amanieu said. Generally, basic blocks should have the property that if any statement gets executed, they all do. There are no control dependencies, and thus data dependencies are the only constraint to reordering.

An Asm block with an infinite loop throws a wrench in that reasoning. So while Terminator might seem arbitrary, it is certainly much less arbitrary than Statement. :D Asm blocks are like functions calls in many ways, so Terminator feels quite natural to me.

[Amanieu]

The new asm! already uses a Terminator. I haven't touched any of the old code around llvm_asm! since it's due to be removed eventually anyways.

[mark-i-m]

I will say that rewriting the assembly to use the new syntax was significantly easier than writing it in the first place and that new system is quite pleasant to use. The RFC text is pretty thorough, so any questions I had when rewriting were easily answered.

On the whole, it took maybe 30m to transform 7 asm blocks, of which 3 where subtle context-switching code.

[mark-i-m]

Also, it might be worthwhile to make it impossible to silence the llvm_asm lint so that people get annoyed and fix it. I don't feel bad doing it because it's the nightly channel!

[Amanieu]

I would like more people to test the new asm! to catch any remaining issues before officially deprecating llvm_asm!.

[stormmq]

Two months to deprecation? Please, I've got so much else I'm working on right now!

[RalfJung]

@stormmq Deprecation doesn't mean removal. Deprecation marks the begin of the final phase of the transition period away from the old macro.

[stormmq]

Given this way of writing asm has been around for years, is there an automated way to transition to the new functionality?

[mark-i-m]

I'm not aware of any, but the RFC text is pretty thorough, and I transitioned 7 asm blocks (3 of which were tricky) in about 30 minutes...

[MatrixMike]

Tue 20 Oct 2020 13:09:57 AEDT

Just so that anyone wandering into this discussion is unaware of the manifestations of these errors I have uploaded to my repository the captured text error files (using >1= {file1} and >2= {file2} ). Two sets of files are available subdir asm and subdir llvm as appropriate for the change on line 53 of my compiler input file.

When I started my interest in Rust I managed to get something working. I use multiple platforms due to availability and poverty to check repeatability. A recent resurgence in interest, due to a 'Meetup' meeting produced some stimulation. You can see my efforts in my repo rust_on_msp. Subsequent attempts to build the same code for modification (normal development) stumbled into these ***asm errors.

The irritating error line :
error[E0658]: use of unstable library feature 'llvm_asm': prefer using the new asm! syntax instead
where the word 'new' seems to be used erroneously has caused plenty of wasted time...

I have started to investigate crates.io/keywords/msp430 .

[Amanieu]

FYI llvm_asm! is being removed in #92816. Please migrate to asm! to keep your code working.