Re: [PATCH] Don't error on coverage mismatch by request

["Richard Guenther" <richard dot guenther at gmail dot com>]

On 1/14/07, Jan Hubicka <hubicka@ucw.cz> wrote:
> >
> > Which makes it even less useful to error on diagnosed mismatch... !?
>
> Well, when the mismatch is diagnosed, you are positive profile is wrong,
> so error seems useful.  The silently ignored cases happens when CFG
> itself does not change much (so checksum match) but the program
> behaviour does.  Bugfixes tend to have this behaviour in general.
>
> > But you mean instead of saying "assuming zero counts" in addition
> > say that "this can result in poorly optimized code" or just saying that
> > in the documentation?
>
> Well, if I try to reconstruct what random user will do, I would expect
> is:
>
> 1) Profile application
> 2) Change something or do profiling wrong
> 3) Compile with feedback getting error
> 4) Searching documentation suggesting that he can use
> -Wcoverage-mismatch to work around
> 5) Compile with feedback, profile and possibly be disappointed starting
> to use -Wcoverage-mismatch more often without thinking about code
> quality consequences.
>
> So I would say that the documentation for -Wcoverage-mismatch should
> warn about likeliness that resulting code will be slow when based on
> outdated profile even when compiler does not diagnoze it.
>
> Also concerning code quality, it would be more meaningful to arrange
> tree-profile to give up early and set cfun->profile to PROFILE_ABSENT
> so we end up with same code as if we didn't attempt to read code in.
> Warning can then say "Will optimize without the profile" or something
> like that...

It certainly makes sense to set PROFILE_ABSENT - just I don't know if
this will work.  We currently have the same 'warning' mode for
no counts at all, no counts for the function and for mismatch with
the patch - return no counters.  I guess this should translate to
PROFILE_ABSENT?  I'll do a cleanup and re-post the patch.

Thanks,
Richard.