[PATCH] Drop profile reproducibility flag as it is not used.

[Jan Hubicka]

> > 
> > I would make this go in separately from the feature itself (it is build
> > machinery change).
> 
> All right.
> 
> > Especially since you say it does not reach
> > reproducibility anyway until we patch hashtables?
> 
> Yep, I'm testing a patch that should improve the reproducible build.
> 
Thanks!
> > I remember we had issues with streaming running in parallel with
> > threads.  Can't we get here corruption without atomic updates of nndoes
> > and the next pointer?
> 
> You are right, it can get into an inconsistent state in the pruning code.
> I likely tend to drop the pruning path now, it's optional feature.

Agreed, lets get the implementation working (i.e. sign bit tracking
non-reproducible gcov merges and gcc consuming it correctly) and care
about pruning incrementally. 

In meantime I seem to have got the firefox inlining working right on GCC
so we can see how well the three settings works.
> 
> > 
> > I also remember that these parlalel updates was pretty bad, because if
> > you have multithreaded concurent update of very frequent indirect
> > branch, like in firefox, the likelyness that update happens between
> > pruning and quite slow stream-out is high.
> 
> Yes.

Yep, but as said in other mail, it makes sense to care about profile
quality with parallel updates if profile-reproducibility=multithreaded
or single.  I do not see point of configuring it to parallel-runs since
it buys you nothing.
> 
> Unfortunately, starting from this point we may set total to a negative value (until
> it's streamed). But training run can still do total++ for each instrumented value.

So this will have effect of decreasing the counter rahter than
increasing.

One interesting datapoint is that firefox train run seems to spend more
time by streaming than by other tasks (becuase llvm training takes 7
minutes and gcc training cca 30 minutes) and if there is parallel task
doing stuff like tab animation it may have enough time to corrupt the
counter considerably.

Unless you see very easy solution, I think we could handle this
incrementally as well.  With basic infrastrucutre on palce and way to
trigger warnings on rejected profiles that would be otherwise useful, we
should get better idea how important this is.

Since we allocate the entries dynamically, perhaps we could steal the
bit somewhere else than in actual counter to avoid concurent updating
issues.

Honza
> 
> Martin
> 
> > 
> > Honza
> > 
>