High Granularity Optimization

speed up various critical packages by using Ofast option
as described in
https://twiki.cern.ch/twiki/bin/view/CMS/HighGranularityCMSSWOptimization
and discussed in April in some Reco/Offline meeting

a small regression is observed in primaryVertices (greatly mitigated w/r/t the very first attempts).
This "cascades" in general tracks and conversions as primaryVertices are used in the seeding
Can you avoid using "==" for floating point, maybe use std::numeric_limits::epsilon() or a small number?