)]}'
{
  "commit": "651dcf61862bf68bedf730fc0259943d5e66adbc",
  "tree": "961907fcae2f888f7b69c8aa1d91da5d80693190",
  "parents": [
    "489aa105d3334665ee1cd1d5921de767b1f6229f",
    "87bb7c92132495b7cb0d476bc11b10ac27c2ea24"
  ],
  "author": {
    "name": "Jacob Pratt",
    "email": "jacob@jhpratt.dev",
    "time": "Fri Jul 10 21:53:52 2026 -0400"
  },
  "committer": {
    "name": "GitHub",
    "email": "noreply@github.com",
    "time": "Fri Jul 10 21:53:52 2026 -0400"
  },
  "message": "Rollup merge of #157690 - ChuanqiXu9:PaddingZero, r\u003ddianqk,RalfJung\n\ncodegen_ssa: pack small const aggregates into immediate stores\n\nClose https://github.com/rust-lang/rust/issues/157373\n\nFor small repr(C) aggregates with padding, direct constant\ninitialization can still lower into field-wise construction plus\nmemcpy. That leaves the backend to rediscover that the whole object\nis a single constant byte pattern.\n\nThis is especially visible for non-zero constant aggregates. Instead\nof materializing them as separate field stores, we want codegen_ssa to\nemit the packed value directly. For example, a value like\n\n    InnerPadded { a: 0, b: 1, c: 0 }\n\ncan otherwise lower to something like\n\n    store i16 0, ptr %val, align 4\n    store i8 1, ptr %val_plus_2, align 2\n    store i32 0, ptr %val_plus_4, align 4\n    call void @llvm.memcpy(..., ptr %val, ...)\n\nwhile this change produces\n\n    store i64 65536, ptr %val, align 4\n    call void @llvm.memcpy(..., ptr %val, ...)\n\nWhy not solve this in LLVM?\n\nAt the problematic lowering point, rustc still knows that the MIR\naggregate is small and fully constant. LLVM only sees a lowered stack\ntemporary built from per-field stores and then copied out. Recovering\nthat packed constant there would require rediscovering front-end\naggregate semantics after lowering, so emitting the packed store in\nrustc is the simpler and more local fix.\n\nWhy not keep the previous typed-copy approach?\n\nAn earlier approach zeroed padding on typed copies whose source could\nbe traced back to a constant assignment. That helped some cases, but it\nalso widened the optimization to runtime copy paths and could introduce\nextra runtime stores purely to maintain padding knowledge. That is not\nan acceptable tradeoff here.\n\nKeep the scope narrow instead: only handle direct MIR aggregates whose\nfields are all constants, and pack them according to the target\nendianness before emitting a single integer store.\n",
  "tree_diff": []
}