Repository navigation
ScalarReplacementOfAggregates causes rustc to emit invalid LLVM debuginfo (and sometimes rustc segfaults) #115113
Description
https://rust.godbolt.org/z/9YvvvcMKj
pub struct Endian;
#[allow(dead_code)]
pub struct EndianSlice<'input> {
slice: &'input [u8],
endian: Endian,
}
pub fn test(s: &[u8]) {
let slice = EndianSlice { slice: s, endian: Endian };
}Compiled with
--emit=llvm-ir -C debuginfo=2 -Zmir-opt-level=0 -Zmir-enable-passes=+ScalarReplacementOfAggregates
Becomes this:
define void @example::test(ptr align 1 %s.0, i64 %s.1) unnamed_addr #0 !dbg !7 {
start:
%slice.dbg.spill1 = alloca { ptr, i64 }, align 8
%slice.dbg.spill = alloca %Endian, align 1
%s.dbg.spill = alloca { ptr, i64 }, align 8
%0 = getelementptr inbounds { ptr, i64 }, ptr %s.dbg.spill, i32 0, i32 0
store ptr %s.0, ptr %0, align 8
%1 = getelementptr inbounds { ptr, i64 }, ptr %s.dbg.spill, i32 0, i32 1
store i64 %s.1, ptr %1, align 8
call void @llvm.dbg.declare(metadata ptr %s.dbg.spill, metadata !22, metadata !DIExpression()), !dbg !30
call void @llvm.dbg.declare(metadata ptr %slice.dbg.spill, metadata !23, metadata !DIExpression()), !dbg !31
%2 = getelementptr inbounds { ptr, i64 }, ptr %slice.dbg.spill1, i32 0, i32 0, !dbg !32
store ptr %s.0, ptr %2, align 8, !dbg !32
%3 = getelementptr inbounds { ptr, i64 }, ptr %slice.dbg.spill1, i32 0, i32 1, !dbg !32
store i64 %s.1, ptr %3, align 8, !dbg !32
call void @llvm.dbg.declare(metadata ptr %slice.dbg.spill1, metadata !23, metadata !DIExpression()), !dbg !31
ret void, !dbg !33
}
<snip>
!22 = !DILocalVariable(name: "s", arg: 1, scope: !7, file: !8, line: 9, type: !12)
!23 = !DILocalVariable(name: "slice", scope: !24, file: !8, line: 10, type: !25, align: 8)ScalarReplacementOfAggregates is on by default in the stable toolchain that is currently being released, and it was turned on in #112002. There is an LLVM assertion which can catch some manifestations of this problem, but in the wild it seems rather hard to actually hit the assertion.
To the best of my knowledge https://bugzilla.redhat.com/show_bug.cgi?id=2226564 is the closest we have to someone hitting this in the wild. I hit it on my own by using -Cdebuginfo=2 -Zinline-mir-threshold=1000 -Zinline-mir-hint-threshold=1000 with -Zbuild-std.
If this becomes a problem when 1.72 goes out, an emergency fix would be just reverting the change to is_enabled in the linked PR.
Activity
cuviper commentedon Aug 22, 2023
Since I'm the one with the "wild" bugzilla, I do plan to apply such a patch when I update to 1.72 in Fedora.
apiraino commentedon Aug 23, 2023
WG-prioritization assigning priority (Zulip discussion).
@rustbot label -I-prioritize +P-critical
cuviper commentedon Aug 23, 2023
I can reproduce this building release cargo with debuginfo:
That's 1.72.0 from the dev-static pre-release build. It also reproduces with
rustc 1.73.0-beta.1 (680cdf816 2023-08-21)andrustc 1.74.0-nightly (c469197b1 2023-08-22), which are both on LLVM 17.cuviper commentedon Aug 23, 2023
That also does trip with LLVM assertions:
1 remaining item
Disable MIR SROA optimization by default
Auto merge of rust-lang#115140 - wesleywiser:turn_off_mir_sroa, r=cuv…
cuviper commentedon Aug 23, 2023
Since #115140 just landed on stable for 1.72, I'm moving this to the 1.73 milestone.
Auto merge of rust-lang#115139 - cjgillot:llvm-fragment, r=nikic
cuviper commentedon Aug 27, 2023
Reopening until we solve 1.73-beta too.
Auto merge of #115139 - cjgillot:llvm-fragment, r=nikic
cuviper commentedon Sep 7, 2023
Hmm, the backport did merge, but I guess this didn't auto-close because the PR wasn't to master?