[llvm] r311371 - [InlineCost] Add cl::opt to allow full inline cost to be computed for debugging purposes.

[vivek pandya via llvm-commits]

Hello all,

I have update the patch https://reviews.llvm.org/D33514
and https://reviews.llvm.org/D37196 for bug
https://bugs.llvm.org/show_bug.cgi?id=32352
please guide me with reviews.

Thanks,
Vivek

On Sun, Aug 27, 2017 at 5:52 AM, Adam Nemet <anemet at apple.com> wrote:

>
> On Aug 26, 2017, at 3:20 PM, Davide Italiano <davide at freebsd.org> wrote:
>
> On Sat, Aug 26, 2017 at 3:00 PM, Davide Italiano <davide at freebsd.org>
> wrote:
>
> On Fri, Aug 25, 2017 at 6:25 PM, Adam Nemet <anemet at apple.com> wrote:
>
>
> On Aug 25, 2017, at 1:11 PM, Davide Italiano <davide at freebsd.org> wrote:
>
> On Mon, Aug 21, 2017 at 1:00 PM, Haicheng Wu via llvm-commits
> <llvm-commits at lists.llvm.org> wrote:
>
> Author: haicheng
> Date: Mon Aug 21 13:00:09 2017
> New Revision: 311371
>
> URL: http://llvm.org/viewvc/llvm-project?rev=311371&view=rev
> Log:
> [InlineCost] Add cl::opt to allow full inline cost to be computed for
> debugging purposes.
>
> Currently, the inline cost model will bail once the inline cost exceeds the
> inline threshold in order to avoid unnecessary compile-time. However, when
> debugging it is useful to compute the full cost, so this command line
> option
> is added to override the default behavior.
>
> I took over this work from Chad Rosier (mcrosier at codeaurora.org).
>
>
> This causes a non-linear increase in the time spent in the inliner for
> us, even with optimization remarks disabled.
> real    0m2.889s
> vs
> real    0m30.429s
>
> I'm under the impression the issue is that for the legacy pass manager
> we create an ORE object on-the-fly (as the inliner is a CGSCC pass,
> and ORE is a FunctionPass analysis), so ORE is always non-null and we
> compute the inlineCost in every case. For the new PM, we can rely on
> proxying, but in the current infrastructure I'm not aware of an easy
> way of obtaining function passes from outer units of IR.
> Adam/Chandler, thoughts?
>
>
> Hi Davide,
>
> Sorry about the delay.  ORE is always set irrespective of whether remarks
> are enabled or not regardless whether you use old or new PM.
>
>
> If nothing comes up, I'm going to pass null instead of ORE in
> InlineSimple to recover from the hit (the feature will be still
> available in the new PM, where we have a much better infrastructure
> for the purpose).
>
>
> I think that this interface is unfortunate conditionalizing on ORE to emit
> remarks.
>
> Also the solution you used from WholeProgDevirt doesn't unfortunately work,
> see https://bugs.llvm.org/show_bug.cgi?id=32352 but it’s OK in the short
> term.
>
> Vivek has been working on the actual solution for this to correctly define
> OptimizationRemarkEmitter::allowExtraAnalysis.  Vivek, do you think you
> can
> get to it soonish?  The API is currently very confusing and I’d like to do
> something about it.
>
> Thanks,
> Adam
>
>
>
> Thanks for your reply, Adam.
> I'm going to disable the feature until the API is fleshed out.
>
>
> Nevermind, ignore my previous reply. What I meant is that I'll leave
> my workaround in place until the API is fleshed out.
>
>
> OK :).
>
>
> Thanks,
>
> --
> Davide
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170827/4ad1ffd3/attachment.html>