[PATCH] D22414: [BranchProbabilityInfo] Change analysis result storage to simplify basic block removal
Xinliang David Li via llvm-commits
llvm-commits at lists.llvm.org
Wed Jul 20 10:07:22 PDT 2016
How about some stats about the number of eraseBB calls from JumpThreading?
An alternative way of fixing the problem which requires slight change in
interface -- the erase interface need to pass in number of successors of
the 'BB' before it is erased. in BPI, you can form the 'Edge' keys from
'BB' and index and erase them.
David
On Wed, Jul 20, 2016 at 9:51 AM, Igor Laevsky <igor at azulsystems.com> wrote:
> igor-laevsky added a comment.
>
> Hi,
>
> I don't have specific build times. This is mostly motivated by the review
> comments in the https://reviews.llvm.org/D20957. Evidence for importance
> of this is that LVI also had linear time EraseBlock and it caused problems
> there. BPI will call EraseBlock exactly as frequently as LVI did, so it's
> natural to assume that performance bottleneck will be in the same place.
>
>
> https://reviews.llvm.org/D22414
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160720/a9129c68/attachment.html>
More information about the llvm-commits
mailing list