On 1/7/20 11:08 AM, Jan Hubicka wrote:
On 1/6/20 8:03 PM, Jan Hubicka wrote:
OK
Actually I am not so sure about this patch - how do we ensure
reproducibility in this case?
ISTM that anyone trying to have reproducible builds shouldn't be using
PGO based optimizations.
OpenSUSE does that. Builds are supposed to be reproducible + PGO is used
for number of core packages (like GCC itself). This was motivation of
original Martin's change to drop TOPN values from profile more
agressively.
I agree with Honza that we should provide as reproducible builds as possible.
On the other hand, we should not be rigid and allow a reasonable sample loss.
That's why I added a parameter that be tweaked at openSUSE side.
Note that original motivation for the patch was your PR :) So that I'm surprised
I don't like the patch much.
I know. However I wonder if this can be done in reproducible way.
My patch deals with TOP N counters for which we expect quite a high
frequency to trigger an optimization. That said, such values should
not be put out of a TOP N counter.
Problem is that small values from profile run polutes the on-disk
counter and eventually renders it invalid.
Considering my patch, how will these small values lead to an invalid counter?
If libgcov before meerging
or streaming dropped alues smaller than TOTAL_COUNT/N from the histogram
it may be enough to fit in the number of entires? (at least in the
testcase they seem very dominated by one value).
This will have probably the same effect as the patch I've suggested.
We could also have more values on disk than used by gcov counter.
But I see it is hard to get with current way libgcov is done.
Yes, it's possible to extend it.
Martin
Honza
