Re: [-fcompare-debug] var tracking options are not optimization options

[Jakub Jelinek <jakub at redhat dot com>]

On Thu, Jan 05, 2017 at 07:13:50PM -0200, Alexandre Oliva wrote:
> > OPTIMIZATION_NODE is created by saving options, computing hash
> > (cl_option_hasher::hash apparently for OPTIMIZATION_NODE does not
> > use cl_optimization_hash, why?), comparing (no cl_optimization_eq,
> > just memcmp for equality) and if there is a match, use it instead.
> > And on the IPA-ICF side, it uses cl_optimization_hash for hash
> > computation and again memcmp for equality.
> 
> You seem to be looking at it from the equality/unequality perspective.
> As far as that is concerned, the hash changes make little difference
> indeed: what was different remains different, and what's the same
> remains the same, maybe with a few extra collisions because certain
> features are no longer regarded as part of the hash.  But remember that,
> even if two different hashed elements map to the same hash number, they
> remain different, and things work just as before (as long as there
> aren't too many collisions, in which case performance may suffer, but
> that's not the case at hand).

You've just changed the hash function and my mail was about the fact that
it is not enough.  Yes, it is needed, but not sufficient.
Consider:

int
foo (int x, int y)
{
  int z = x + y;
  return x * y;
}

__attribute__((optimize ("no-var-tracking"))) int
bar (int x, int y)
{
  int z = x + y;
  return x * y;
}

or something similar (dunno if you don't also need to do
"no-var-tracking-assignments" too).  With your patch, both functions
will hash the same (that is ok), but as ICF for functions that hash the same
also performs memcmp on the OPTIMIZATION_NODE content, they will compare
the same in one case (-g0) and not in the other one (-g) and so ICF will
merge them in one case and not in the other one.
BTW, seems the above exact case ICEs actually.

> What needed changing as far as I was concerned, however, was not
> equality of code units (for want of a better name for the combination of
> code and compile options) within one translation group (possibly
> multiple units), but rather iteration order on the hash table when
> comparing two compilations of the same translation group with slightly
> different options that should still generate the same executable code.

We need to deal not just with the iteration order, but also with equality
of functions, otherwise ICF will do something depending on -g vs. -g0.

	Jakub