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

Assembly comments affect generated code. #3298

Closed
jld opened this issue Aug 29, 2012 · 8 comments
Closed

Assembly comments affect generated code. #3298

jld opened this issue Aug 29, 2012 · 8 comments
Assignees
Labels
A-codegen Area: Code generation E-hard Call for participation: Hard difficulty. Experience needed to fix: A lot. I-slow Issue: Problems and improvements with respect to performance of generated code. P-low Low priority

Comments

@jld
Copy link
Contributor

jld commented Aug 29, 2012

Given this program:

fn main() {
        let x = @3;
        let mut a = 0;
        for uint::range(1, *x) |_i| {
                a += 1;
        }
        assert(a == 2);
}

compiling with -S -O yields an assembly file containing this, which is what's left of the uint::range loop (as output by grep -C2 inc):

        .align  16, 0x90
.LBB2_4:
        incq    %rcx
        cmpq    %rcx, %rax
        jne     .LBB2_4

But compiling with -c -O and disassembling shows a file where the loop has been entirely removed. However, compiling with -S -Zno-asm-comments -O is faithful to the -c output; and with --save-temps we can see that the bitcode is identical between -c and -S -Zno-asm-comments and nontrivially different (more than just the comments) for -S.

So there's something about the asm comments that makes LLVM think they have effects.

@nikomatsakis
Copy link
Contributor

This is a known issue. However, the assembly comments are not generated unless you run with -S.

@nikomatsakis
Copy link
Contributor

The problem is that the technique we use to inject comments is to insert an assembly block, which LLVM assumes could have arbitrary side-effects. There should be another way to do that...but I'm not sure what it is.

@jld
Copy link
Contributor Author

jld commented Aug 30, 2012

The other problem is that a compiler is, more generally, not unreasonable in deleting operations which have no outputs that aren't unused and no effects on memory or other state. One is warned about this in the GCC asm statement documentation, for example (and in GCC's case, for extra confusion, a non-volatile asm with no outputs at all appears to be implicitly made volatile early in compilation, presumably under the assumption that unconditionally removing it was not the intended result).

Clearly there's some way of tracking which parts of the .text are which in order to have debug info, but that doesn't directly help with reading the assembly….

(Edited for what I hope is clarity.)

@nikomatsakis
Copy link
Contributor

The defaults have been changed. We never generate assembly comments without -Z asm-comments. I am leaving the bug open because it'd be good to find a better way to inject debugging comments.

@thestinger
Copy link
Contributor

This is still an issue.

@huonw
Copy link
Member

huonw commented Sep 23, 2013

Some searching yield two threads (1, 2) which suggest that one can attach a metadata string to the LLVM instruction and get the ASMPrinter to print it. This may mean some comments get lost entirely due to optimisations (e.g. DCE completely killing an instruction will presumably take its associated MDStrings with it).

@pnkfelix
Copy link
Member

accepted for P-low.

@emberian emberian self-assigned this Mar 25, 2015
@alexcrichton
Copy link
Member

This option no longer exists, so closing.

bors pushed a commit to rust-lang-ci/rust that referenced this issue May 15, 2021
Use the same rule between function and macro
RalfJung pushed a commit to RalfJung/rust that referenced this issue Feb 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-codegen Area: Code generation E-hard Call for participation: Hard difficulty. Experience needed to fix: A lot. I-slow Issue: Problems and improvements with respect to performance of generated code. P-low Low priority
Projects
None yet
Development

No branches or pull requests

7 participants