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

Tracking Issue for LLVM-style inline assembly (llvm_asm) #70173

Closed
Amanieu opened this issue Mar 20, 2020 · 18 comments · Fixed by #92816
Closed

Tracking Issue for LLVM-style inline assembly (llvm_asm) #70173

Amanieu opened this issue Mar 20, 2020 · 18 comments · Fixed by #92816
Labels
A-inline-assembly Area: Inline assembly (`asm!(…)`) B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@Amanieu
Copy link
Member

Amanieu commented Mar 20, 2020

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

@Amanieu Amanieu added B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. A-inline-assembly Area: Inline assembly (`asm!(…)`) T-lang Relevant to the language team, which will review and decide on the PR/issue. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. labels Mar 20, 2020
@mark-i-m
Copy link
Member

cc #68404

@jonas-schievink jonas-schievink added B-unstable Blocker: Implemented in the nightly compiler and unstable. and removed B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. labels May 8, 2020
paulkernfeld pushed a commit to paulkernfeld/generator-rs that referenced this issue May 22, 2020
Replace uses of asm! with llvm_asm!, add the llvm_asm feature
[Tracking Issue for LLVM-style inline
assembly](rust-lang/rust#70173)
`cargo test` now passes for me with rustc 1.45.0-nightly
(9310e3bd4 2020-05-21)
@RalfJung
Copy link
Member

RalfJung commented Jun 1, 2020

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
Copy link
Member Author

Amanieu commented Jun 1, 2020

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
Copy link
Contributor

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
Copy link
Contributor

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

Amanieu commented Jun 1, 2020

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
Copy link
Contributor

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

RalfJung commented Jun 1, 2020

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
Copy link
Member Author

Amanieu commented Jun 1, 2020

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
Copy link
Member

mark-i-m commented Jun 2, 2020

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
Copy link
Member

mark-i-m commented Jun 2, 2020

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
Copy link
Member Author

Amanieu commented Jun 2, 2020

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

Xudong-Huang pushed a commit to Xudong-Huang/generator-rs that referenced this issue Jun 10, 2020
Replace uses of asm! with llvm_asm!, add the llvm_asm feature
[Tracking Issue for LLVM-style inline
assembly](rust-lang/rust#70173)
`cargo test` now passes for me with rustc 1.45.0-nightly
(9310e3bd4 2020-05-21)
@stormmq
Copy link

stormmq commented Jun 25, 2020

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

@RalfJung
Copy link
Member

RalfJung commented Jun 26, 2020

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

@stormmq
Copy link

stormmq commented Jun 26, 2020

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
Copy link
Member

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
Copy link

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
Copy link
Member Author

Amanieu commented Jan 13, 2022

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

@bors bors closed this as completed in a34c079 Jan 17, 2022
sirhcel added a commit to sirhcel/esp-idf-hal that referenced this issue Jan 18, 2022
See
rust-lang/rust#70173 (comment).
This gets shipped starting with nightly 2022-01-17.
sirhcel added a commit to sirhcel/esp-idf-hal that referenced this issue Jan 18, 2022
See
rust-lang/rust#70173 (comment).
This gets shipped starting with nightly 2022-01-17.
sirhcel added a commit to sirhcel/esp-idf-hal that referenced this issue Jan 19, 2022
The macro llvm_asm! finally got removed as 'asm!' got stabilized in
nightly. See
rust-lang/rust#70173 (comment)
and this gets shipped starting with nightly 2022-01-17.

According to
https://users.rust-lang.org/t/volatile-option-in-new-asm-macro/44289/2
assembly is volatile by default with asm!.
sirhcel added a commit to sirhcel/esp-idf-hal that referenced this issue Jan 19, 2022
The macro llvm_asm! finally got removed as 'asm!' got stabilized in
nightly. See
rust-lang/rust#70173 (comment)
and this gets shipped starting with nightly 2022-01-17.

According to
https://users.rust-lang.org/t/volatile-option-in-new-asm-macro/44289/2
assembly is volatile by default with asm!.
sirhcel added a commit to sirhcel/esp-idf-hal that referenced this issue Jan 19, 2022
The macro llvm_asm! finally got removed as 'asm!' got stabilized in
nightly. See
rust-lang/rust#70173 (comment)
and this gets shipped starting with nightly 2022-01-17.

According to
https://users.rust-lang.org/t/volatile-option-in-new-asm-macro/44289/2
assembly is volatile by default with asm!.
sirhcel added a commit to sirhcel/esp-idf-hal that referenced this issue Jan 19, 2022
The macro llvm_asm! finally got removed as 'asm!' got stabilized in
nightly. See
rust-lang/rust#70173 (comment)
and this gets shipped starting with nightly 2022-01-17.

According to
https://users.rust-lang.org/t/volatile-option-in-new-asm-macro/44289/2
assembly is volatile by default with asm!.
ivmarkov pushed a commit to esp-rs/esp-idf-hal that referenced this issue Jan 19, 2022
The macro llvm_asm! finally got removed as 'asm!' got stabilized in
nightly. See
rust-lang/rust#70173 (comment)
and this gets shipped starting with nightly 2022-01-17.

According to
https://users.rust-lang.org/t/volatile-option-in-new-asm-macro/44289/2
assembly is volatile by default with asm!.
flip1995 pushed a commit to flip1995/rust that referenced this issue Jan 27, 2022
Remove deprecated LLVM-style inline assembly

The `llvm_asm!` was deprecated back in rust-lang#87590 1.56.0, with intention to remove
it once `asm!` was stabilized, which already happened in rust-lang#91728 1.59.0. Now it
is time to remove `llvm_asm!` to avoid continued maintenance cost.

Closes rust-lang#70173.
Closes rust-lang#92794.
Closes rust-lang#87612.
Closes rust-lang#82065.

cc `@rust-lang/wg-inline-asm`

r? `@Amanieu`
bjorn3 pushed a commit to bjorn3/rust that referenced this issue Feb 23, 2022
Remove deprecated LLVM-style inline assembly

The `llvm_asm!` was deprecated back in rust-lang#87590 1.56.0, with intention to remove
it once `asm!` was stabilized, which already happened in rust-lang#91728 1.59.0. Now it
is time to remove `llvm_asm!` to avoid continued maintenance cost.

Closes rust-lang#70173.
Closes rust-lang#92794.
Closes rust-lang#87612.
Closes rust-lang#82065.

cc `@rust-lang/wg-inline-asm`

r? `@Amanieu`
calebcartwright pushed a commit to calebcartwright/rust that referenced this issue Mar 30, 2022
Remove deprecated LLVM-style inline assembly

The `llvm_asm!` was deprecated back in rust-lang#87590 1.56.0, with intention to remove
it once `asm!` was stabilized, which already happened in rust-lang#91728 1.59.0. Now it
is time to remove `llvm_asm!` to avoid continued maintenance cost.

Closes rust-lang#70173.
Closes rust-lang#92794.
Closes rust-lang#87612.
Closes rust-lang#82065.

cc `@rust-lang/wg-inline-asm`

r? `@Amanieu`
BaybyPig0329 added a commit to BaybyPig0329/esp-idf-hal that referenced this issue Apr 21, 2024
The macro llvm_asm! finally got removed as 'asm!' got stabilized in
nightly. See
rust-lang/rust#70173 (comment)
and this gets shipped starting with nightly 2022-01-17.

According to
https://users.rust-lang.org/t/volatile-option-in-new-asm-macro/44289/2
assembly is volatile by default with asm!.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-inline-assembly Area: Inline assembly (`asm!(…)`) B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants