>
> Regarding the function level detail being too noisy : I sort of agree with
> that
> comment. But I am of the opinion that I would rather leave it to the user to
> infer the profile quality as per the application characteristics.
Makes sense I guess. But I would keep the drill down as opt-
Usecase : The usecase is to get a high-level assessment of the quality of
function profiles available (-Wcoverage-mismatch and -Wmissing-profile are
useful in the same spirit). For large codebases, it is useful to make the
profile quality information more handy for ease of development. Doing a ful
On 11/21/18 4:47 AM, Andi Kleen wrote:
> Indu Bhagat writes:
>
>> Proposal to add diagnostics to know which functions were not run in the
>> training run in FDO.
>
> Don't you think the warning will be very noisy? I assume most programs
> have a lot of cold error handling functions etc. that are
Indu Bhagat writes:
> Proposal to add diagnostics to know which functions were not run in the
> training run in FDO.
Don't you think the warning will be very noisy? I assume most programs
have a lot of cold error handling functions etc. that are never executed
in a normal execution.
Like how do
Proposal to add diagnostics to know which functions were not run in the
training run in FDO.
Motivation :
When using FDO, it is often desirable to know the quality of function profile.
This means knowing which functions have STALE, NO/MISSING or ZERO profiles. GCC
has diagnostics for STALE (Wcove
