rust-lang / rust-lang/rust

Fails to optimize away trivial ownership move of Vec in high optimization levels

Open
#140,057 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

C-bug C-optimization I-heavy T-compiler
Dominant language
Rust
Stars
119k
Forks
16.1k
PR merge metrics
PR metrics pending

Description

I tried these codes:
https://godbolt.org/z/3je47cr9a

#![allow(dead_code)]
#![allow(non_camel_case_types)]

struct trie_node {
    content: Vec<String>,
    children: Vec<trie_node>,
}

#[no_mangle]
fn print_str_vector(vector: Vec<String>) {
    for string in &vector {
        println!("{}", *string);
    }
}

pub fn main() {
    let mut node: trie_node = trie_node {
        content: Vec::new(),
        children: Vec::new(),
    };
    let v = vec!["123".to_string(), "abc".to_string()];
    node.content = vec!["123".to_string(), "abc".to_string()];
    print_str_vector(v);
    print_str_vector(node.content.clone());
}

and:

#![allow(dead_code)]
#![allow(non_camel_case_types)]
struct trie_node {
    content: Vec<String>,
    children: Vec<trie_node>,
}

#[no_mangle]
fn print_str_vector(vector: Vec<String>) {
    for string in &vector {
        println!("{}", *string);
    }
}
pub fn main() {
    let mut node: trie_node = trie_node {
        content: Vec::new(),
        children: Vec::new(),
    };
    let v = vec!["123".to_string(), "abc".to_string()];
    node.content = vec!["123".to_string(), "abc".to_string()];
    print_str_vector(v);
    let temp_bridge_1080 = node.content;
    print_str_vector(temp_bridge_1080.clone());
}

I expected to see this happen:
Both expressions should produce identical assembly code.

Instead, this happened:
The second version of the code generated approximately 200 more lines of assembly compared to the first version.

The additional assembly appears to stem from the line: let temp_bridge_1080 = node.content;
Since this is a simple move operation (zero-cost abstraction in Rust), it should not introduce any runtime overhead or code bloat. This suggests a potential missed optimization opportunity in the compiler.

Could you please review them? Thank you!

Meta
rustc 1.85.0-nightly (d117b7f21 2024-12-31)
binary: rustc
commit-hash: d117b7f211835282b3b177dc64245fff0327c04c
commit-date: 2024-12-31
host: x86_64-unknown-linux-gnu
release: 1.85.0-nightly
LLVM version: 19.1.6

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

The report provides two Rust snippets and Godbolt links, with no repository file or test named. Start by reproducing the optimized assembly difference with the reported rustc nightly version, then trace the relevant compiler optimization path. Done means the equivalent ownership-move forms produce equivalent optimized assembly, with a regression test if the compiler test location is identified.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
compilers, performance
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.