llvm dev - Apr 2017 - Saving Compile Time in InstCombine

On Fri, Apr 14, 2017 at 2:19 PM, Mikulin, Dmitry
<dmitry.mikulin at sony.com> wrote:
>
>>> Is this a run with debug info? i.e. are you passing -g to the
per-TU
>>> pipeline? I'm inclined to think this is mostly an additive
effect
>>> adding matchers here and there that don't really hurt small
testcases
>>> but we pay the debt over time (in particular for LTO). Side note, I
>>> noticed (and others did as well) that instcombine is way slower
with
>>> `-g` on (one of the reasons could be we walking much longer use
lists,
>>> due to the dbg use). Do you have numbers of instcombine ran on IR
with
>>> and without debug info?
>>
>> I do have the numbers for the same app with and without debug info. The
results above are for the no-debug version.
>>
>> Total execution time of -O3 is 34% slower with debug info. The size of
the debug IR is 162M vs 39M no-debug. Both profiles look relatively similar with
the exception of bit code writer and verifier taking a larger share in the -g
case.
>>
>> Looking at InstCombine, it’s 23% slower. One notable thing is that
CallInst takes significantly larger share with -g: 5s vs 13s, which translates
to about half of the InstCombine slowdown. Need to understand why.
>
> Ah, it’s all those calls to @llvm.dbg.* functions. I’ll explore if they can
be safely ignored by InstCombine.
>
>
I took a look and saw no immediate problems, also discussed with David
Majnemer on IRC, who thinks we should just bail out early.

-- 
Davide

"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare

I think the easy way to ignore them is to add visitDbgDeclareInst and
visitDbgValueInst to the InstCombine visitor tree and then just return
nullptr from them.

~Craig

On Fri, Apr 14, 2017 at 2:23 PM, Davide Italiano via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On Fri, Apr 14, 2017 at 2:19 PM, Mikulin, Dmitry
> <dmitry.mikulin at sony.com> wrote:
> >
> >>> Is this a run with debug info? i.e. are you passing -g to the
per-TU
> >>> pipeline? I'm inclined to think this is mostly an additive
effect
> >>> adding matchers here and there that don't really hurt
small testcases
> >>> but we pay the debt over time (in particular for LTO). Side
note, I
> >>> noticed (and others did as well) that instcombine is way
slower with
> >>> `-g` on (one of the reasons could be we walking much longer
use lists,
> >>> due to the dbg use). Do you have numbers of instcombine ran on
IR with
> >>> and without debug info?
> >>
> >> I do have the numbers for the same app with and without debug
info. The
> results above are for the no-debug version.
> >>
> >> Total execution time of -O3 is 34% slower with debug info. The
size of
> the debug IR is 162M vs 39M no-debug. Both profiles look relatively similar
> with the exception of bit code writer and verifier taking a larger share in
> the -g case.
> >>
> >> Looking at InstCombine, it’s 23% slower. One notable thing is that
> CallInst takes significantly larger share with -g: 5s vs 13s, which
> translates to about half of the InstCombine slowdown. Need to understand
> why.
> >
> > Ah, it’s all those calls to @llvm.dbg.* functions. I’ll explore if
they
> can be safely ignored by InstCombine.
> >
> >
>
> I took a look and saw no immediate problems, also discussed with David
> Majnemer on IRC, who thinks we should just bail out early.
>
> --
> Davide
>
> "There are no solved problems; there are only problems that are more
> or less solved" -- Henri Poincare
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170414/871c6818/attachment.html>

This change recovered the time lost processing @llvm.dbg intrinsics:

diff --git a/lib/Transforms/InstCombine/InstCombineInternal.h
b/lib/Transforms/InstCombine/InstCombineInternal.h
index 7100006..e70613c 100644
--- a/lib/Transforms/InstCombine/InstCombineInternal.h
+++ b/lib/Transforms/InstCombine/InstCombineInternal.h
@@ -290,6 +290,7 @@ public:
   Instruction *visitSelectInst(SelectInst &SI);
   Instruction *visitCallInst(CallInst &CI);
   Instruction *visitInvokeInst(InvokeInst &II);
+  Instruction *visitDbgInfoIntrinsic(DbgInfoIntrinsic &CI) { return
nullptr; }

   Instruction *SliceUpIllegalIntegerPHI(PHINode &PN);
   Instruction *visitPHINode(PHINode &PN);

The –O3 compile time speedup on my benchmark is ~3%. No llvm test failures.
Safe to commit?


From: Craig Topper <craig.topper at gmail.com>
Date: Friday, April 14, 2017 at 2:31 PM
To: Davide Italiano <davide at freebsd.org>
Cc: "Mikulin, Dmitry" <dmitry.mikulin at sony.com>, llvm-dev
<llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] Saving Compile Time in InstCombine

I think the easy way to ignore them is to add visitDbgDeclareInst and
visitDbgValueInst to the InstCombine visitor tree and then just return nullptr
from them.

~Craig

On Fri, Apr 14, 2017 at 2:23 PM, Davide Italiano via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
On Fri, Apr 14, 2017 at 2:19 PM, Mikulin, Dmitry
<dmitry.mikulin at sony.com<mailto:dmitry.mikulin at sony.com>>
wrote:
>
>>> Is this a run with debug info? i.e. are you passing -g to the
per-TU
>>> pipeline? I'm inclined to think this is mostly an additive
effect
>>> adding matchers here and there that don't really hurt small
testcases
>>> but we pay the debt over time (in particular for LTO). Side note, I
>>> noticed (and others did as well) that instcombine is way slower
with
>>> `-g` on (one of the reasons could be we walking much longer use
lists,
>>> due to the dbg use). Do you have numbers of instcombine ran on IR
with
>>> and without debug info?
>>
>> I do have the numbers for the same app with and without debug info. The
results above are for the no-debug version.
>>
>> Total execution time of -O3 is 34% slower with debug info. The size of
the debug IR is 162M vs 39M no-debug. Both profiles look relatively similar with
the exception of bit code writer and verifier taking a larger share in the -g
case.
>>
>> Looking at InstCombine, it’s 23% slower. One notable thing is that
CallInst takes significantly larger share with -g: 5s vs 13s, which translates
to about half of the InstCombine slowdown. Need to understand why.
>
> Ah, it’s all those calls to @llvm.dbg.* functions. I’ll explore if they can
be safely ignored by InstCombine.
>
>
I took a look and saw no immediate problems, also discussed with David
Majnemer on IRC, who thinks we should just bail out early.

--
Davide

"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170417/8db6a0e5/attachment.html>