[PATCH] D22141: [BFI] Add option to lazily calculate BFI

[Duncan P. N. Exon Smith via llvm-commits]

Just confirming my off-line conversation with Adam.  LazyBFI needs a fundamentally different contract than the current BFI, and having clients opt-in seems right.

Long term: I imagine once the new pass manager is the one-true-way there could be a way to unify LazyBFI and BFI (it solves everything, right?), but I don't see how we could reasonably block improving optimization remarks on that.

> On 2016-Jul-11, at 14:18, Adam Nemet <anemet at apple.com> wrote:
> 
> anemet added a comment.
> 
>> In http://reviews.llvm.org/D22141#478534, @davidxl wrote:
> 
>> 
> 
>>> I suggest just making BFI lazy itself (when getBlockFreq() is first called ...). In fact  I think the laziness handling should be in BlocFrequencyInfoImpl class. By so doing, MBFI can get the laziness automatically as well.
> 
>> 
> 
> 
> I've tried and unfortunately, I don't think this will work.  I saw two issues:
> 
> a. LoopInfo is freed by the time block frequencies are requested
> 
>  This can be fixed by making users of BFI also dependent on LI but that's an overkill for existing users
> 
> b. The pass starts modifying the CFG and when it tries to update the frequencies LI and the CFG are already inconsistent
> 
> I think that these issues (there maybe more) are difficult to fix in the context of existing BFI's users.  My new proposal is to introduce a new analysis, LazyBFI.  Then, new users could opt in by complying with LBFI's requirements:
> 
> 1. require LI and BPI as well (I will add an 'required' enumerator)
> 
> 2. compute BFI before making any CFG changes
> 
> The analysis would effectively consist of the LazyBFI class I had earlier.  It will only cover IR BFI for now but we could later template-ize it to also work with BFI.
> 
> I talked with Duncan about this and he was fine with this idea.  Let me know your thoughts.
> 
> Adam
> 
> 
> http://reviews.llvm.org/D22141
> 
> 
>