[llvm] r263275 - [ThinLTO] Support for reference graph in per-module and combined summary.

[Mehdi Amini via llvm-commits]

> On Mar 21, 2016, at 4:05 PM, Duncan P. N. Exon Smith via llvm-commits <llvm-commits at lists.llvm.org> wrote:
> 
>> 
>> On 2016-Mar-21, at 08:48, Xinliang David Li <xinliangli at gmail.com> wrote:
>> 
>> 
>> This is guarded under PGO flag only.
>> 
>> PGO and -flto=thin
>> 
>> 
>> 
>> I'm pretty surprised to see these here.
>> 
>> This is unfortunate  -- the block level profile count information is discarded and we need to use BFI to reconstruct it.  One way to remove this dependency  is to use new analysis pass to annotate callsites with profile count meta data.
>> 
>> Is this new analysis pass currently available? If so, can you point me to it? The above code was used in other locations in the compiler that needed similar info.
>> 
>> 
>> No -- not I am aware of.  I was just suggesting if it is considered a problem, this is one way to solve it.
>> 
> 
> I think somehow running a pass *before* writing out the bitcode would
> be better.  I'm not sure attaching something to the calls is the best
> way, or if Mehdi's idea to generate a FunctionIndex that's passed in
> to the bitcode reader makes more sense.
> 
> Or, maybe the FunctionIndex should be attached to the Module?

I thought about that, but I'm reluctant to it because it is hard to guarantee any synchronization.
The issue is that the summary is a serialization of some analyses ran over the IR. Usually we don't serialize / keep analyses result, this is probably a first timer and LLVM is not well equipped to deal with that.

Maybe that moving forward, we can imagine a generic mechanism to serialize analyses results, and reload them, so that the pipeline can be stopped/resumed at any point, but we're not there yet...

-- 
Mehdi


> 
>> David
>> 
>> 
>> 
>> Thanks,
>> Teresa
>> 
>> 
>> David
>> 
>> 
>> 
>> 
>>> +  }
>>> +
>>>  Stream.EnterSubblock(bitc::FUNCTION_BLOCK_ID, 4);
>>>  VE.incorporateFunction(F);
>> 
>> 
>>> Modified: llvm/trunk/lib/Bitcode/Writer/LLVMBuild.txt
>>> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Bitcode/Writer/LLVMBuild.txt?rev=263275&r1=263274&r2=263275&view=diff
>>> ==============================================================================
>>> --- llvm/trunk/lib/Bitcode/Writer/LLVMBuild.txt (original)
>>> +++ llvm/trunk/lib/Bitcode/Writer/LLVMBuild.txt Fri Mar 11 12:52:24 2016
>>> @@ -19,4 +19,4 @@
>>> type = Library
>>> name = BitWriter
>>> parent = Bitcode
>>> -required_libraries = Core Support
>>> +required_libraries = Analysis Core Support
>> 
>> This means that `llvm-as` now has a dependency on lib/Analysis... which
>> is surprising.
>> 
>> I feel like we've done something fundamentally wrong if we have to
>> run expensive analyses in order to write out IR.
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>> 
>> 
>> 
>> 
>> -- 
>> Teresa Johnson |	 Software Engineer |	 tejohnson at google.com |	 408-460-2413
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits