https://bugs.llvm.org/show_bug.cgi?id=50099

            Bug ID: 50099
           Summary: [NewPM] Inliner: Certain destructor calls are no
                    longer inlined, preventing SROA, causing +10% runtime
                    perf regression
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Interprocedural Analyses
          Assignee: [email protected]
          Reporter: [email protected]
                CC: [email protected]

Created attachment 24799
  --> https://bugs.llvm.org/attachment.cgi?id=24799&action=edit
unoptimized IR for reproduction

I'm seeing a rather big +10% runtime perf regression
from new-pm switch on a certain codepath.

I don't really have a small workable testcase yet, 
but there's a full self-contained reproducer attached.

Here's how we can see that the problem is there:

$ clang -O3 -o old.ll -S -emit-llvm orig.ll -flegacy-pass-manager
$ clang -O3 -o new.ll -S -emit-llvm orig.ll 
$ llvm-diff old.ll new.ll
<...>
function @_ZN8rawspeed6BufferD2Ev exists only in right module
<...>
in function _ZN8rawspeed23PanasonicDecompressorV511ProxyStream10parseBlockEv:
  in block %entry:
    >   %FirstSection = alloca %"class.rawspeed::Buffer", align 8
    >   %SecondSection = alloca %"class.rawspeed::Buffer", align 8
    >   %0 = bitcast %"class.rawspeed::Buffer"* %FirstSection to i8*
    >   call void @llvm.lifetime.start.p0i8(i64 16, i8* nonnull %0) #17
    >   tail call void @llvm.experimental.noalias.scope.decl(metadata !135)
        %pos.i = getelementptr inbounds
%"class.rawspeed::PanasonicDecompressorV5::ProxyStream",
%"class.rawspeed::PanasonicDecompressorV5::ProxyStream"* %this, i64 0, i32 0,
i32 1
        %0 = load i32, i32* %pos.i, align 4, !tbaa !4, !noalias !9
    >   tail call void @llvm.experimental.noalias.scope.decl(metadata !138)

<...>

Inliner/inline cost model isn't something i'm familiar with,
so i'm posting this as is. Any suggestions how this can be approached from the
LLVM side?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

Reply via email to