[LLVMdev] RFC - Improvements to PGO profile support

Diego Novillo dnovillo at google.com
Wed Mar 11 12:49:50 PDT 2015



On 03/10/15 21:30, Ivan Baev wrote:
>
> [ivan] What new data type do you suggest? Increasing it to 64 bit for
> 64-bit architectures would be reasonable, and would reduce the need of
> scaling counts.

Yes. That's what we have in mind. MD_prof would eventually become a 
64bit integer.
>>
>> [ivan] Scaling branch counts when inlining looks good, but the 
>> current PGO support doesn't maintain function entry counts at LLVM 
>> IR. How do you plan to maintain these at LLVM IR?
Well, we'd have to incrementally update the entry counts as inlining 
happens while scaling the MD_prof counts in the IR. This is a bit far 
out right now. The inliner is not even capable of reading profiles 
today. This is the part of the plan that will happen much further down 
the road.

>
>>
>> opt -analyze -block-freq test1.10.ll
> Printing analysis 'Block Frequency Analysis' for function 'main':
> block-frequency-info: main
>   - entry: float = 1.0, int = 8
>   - for.cond: float = 11.0, int = 87
>   - for.cond1: float = 110.0, int = 879
>   - for.cond4: float = 1100.0, int = 8799
>   - for.body6: float = 1000.0, int = 7999
>   - for.inc7: float = 100.0, int = 799
>   - for.inc10: float = 10.0, int = 79
>   - for.end12: float = 1.0, int = 8
>   - for.cond13: float = 11.0, int = 87
>   - for.cond16: float = 1010.0, int = 8079
>   - for.body18: float = 1000.0, int = 7999
>   - for.inc22: float = 10.0, int = 79
>   - for.end24: float = 1.0, int = 8
>   - for.cond26: float = 1001.0, int = 8007
>   - for.body28: float = 1000.0, int = 7999
>   - for.end31: float = 1.0, int = 8
>
> the three calls to bar() get the correct count of 1000.
> We should try to remove the limitation of 4096 in the block frequency
> propagation algorithm if possible.
Long term, the presence of real profile data would make the frequency 
propagator unnecessary. In the shorter term, coming up with some 
intermediate fix to this is certainly possible. I'd rather continue this 
discussion in the bug itself (https://llvm.org/bugs/show_bug.cgi?id=22719)


Diego.



More information about the llvm-dev mailing list