[PATCH] D22694: [Inliner, OptDiag] Add hotness attribute to opt diagnostics

[Adam Nemet via llvm-commits]

anemet added a comment.

In https://reviews.llvm.org/D22694#500213, @eraman wrote:

> In https://reviews.llvm.org/D22694#500141, @anemet wrote:
>
> > In https://reviews.llvm.org/D22694#500037, @eraman wrote:
> >
> > > This computes DominatorTree, LoopInfo, BPI and BFI for *every callsite* that is considered for inlining. Even though this is (I assume) turned off by default, it's still very expensive.
> >
> >
> > Certainly it is off by default and it's meant as a performance analysis tool so the budget is different.
>
>
> Yes, I understand that this is a reporting tool and so the compilation time is not a major constraint. I was wondering if this makes it practical for use in real applications. Perhaps it is. Have you run this on anything large (SPEC, for example) and measured the overhead? I don't have any objections to this patch if you have measured the overhead and found them reasonable.


No, I haven't run it with anything yet.  I can keep this patch local for now and start doing the evaluation and go from there.

> 

> 

> >   That said, we can I guess cache ORE per caller and only invalidate it once we inline.  Does that sound reasonable to you?

> 

> 

> That'll certainly reduce the overhead in the cases where inlining is considered, but does not happen. I am not sure if it is worth the additional complexity though. If you go this route, please isolate the changes to within ORE and invalidate this in emitOptimizationRemark.


Yes, certainly.  It would be good if as little of this as possible would spill over into the inliner.


https://reviews.llvm.org/D22694