Skip to content

Debug info affects output from "opt -inline -adce" #42636

@mikaelholmen

Description

@mikaelholmen
Bugzilla Link 43291
Resolution FIXED
Resolved on Oct 28, 2019 10:42
Version trunk
OS Linux
Blocks #37076
Attachments ll reproducer
CC @adrian-prantl,@bjope,@dwblaikie,@JDevlieghere,@jmorse,@pogo59,@pogo59,@vedantk
Fixed by commit(s) 80cb2ce

Extended Description

Reprocuce with:

opt -S -o - bbi-32603.ll -inline -adce

which produces

define i16 @​g() !dbg !​33 {
%volatileloadslot.i = alloca %rec1198
call void @​llvm.dbg.value(metadata i16 0, metadata !​30, metadata !DIExpression()), !dbg !​36
%volatileloadslot.0..sroa_cast.i = bitcast %rec1198* %volatileloadslot.i to i8*, !dbg !​38
call void @​llvm.lifetime.start.p0i8(i64 4, i8* %volatileloadslot.0..sroa_cast.i)
%volatileloadslot.0..sroa_cast1.i = bitcast %rec1198* %volatileloadslot.i to i8*
call void @​llvm.lifetime.end.p0i8(i64 4, i8* %volatileloadslot.0..sroa_cast1.i)
br label %bb1

bb1: ; preds = %0
ret i16 0
}

If we just remove

, !dbg !​32

from

%volatileloadslot.0..sroa_cast = bitcast %rec1198* %volatileloadslot to i8*, !dbg !​32

in the input we instead get:

define i16 @​g() !dbg !​30 {
%volatileloadslot.i = alloca %rec1198
%l.6.i = alloca [3 x i32]
%1 = bitcast [3 x i32]* %l.6.i to i8*
call void @​llvm.lifetime.start.p0i8(i64 12, i8* %1)
%volatileloadslot.0..sroa_cast.i = bitcast %rec1198* %volatileloadslot.i to i8*
call void @​llvm.lifetime.start.p0i8(i64 4, i8* %volatileloadslot.0..sroa_cast.i)
%volatileloadslot.0..sroa_cast1.i = bitcast %rec1198* %volatileloadslot.i to i8*
call void @​llvm.lifetime.end.p0i8(i64 4, i8* %volatileloadslot.0..sroa_cast1.i)
%2 = bitcast [3 x i32]* %l.6.i to i8*
call void @​llvm.lifetime.end.p0i8(i64 12, i8* %2)
br label %bb1

bb1: ; preds = %0
ret i16 0
}

Looking at -debug printouts the first difference we see is that adce removes the

call void @​llvm.dbg.value(metadata i16 %k.4.par, metadata !​30, metadata !DIExpression()), !dbg !​31

when the

, !dbg !​32

isn't present on the bitcast, and then before we run the inliner we see this

CGSCCPASSMGR: Pass Dirtied SCC: Function Pass Manager
CGSCCPASSMGR: Refreshing SCC with 1 nodes:
Call graph node for function: 'f'<<0x643aed0>> #uses=2

CGSCCPASSMGR: SCC Refresh didn't change call graph.

which isn't there when don't remove the

, !dbg !​32

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugzillaIssues migrated from bugzillaipoInterprocedural optimizations

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions