On Feb 19, 2012, Richard Sandiford <rdsandif...@googlemail.com> wrote:

> I have to admit I still don't like these changes
> I'd much rather we kept to the original dag.

I'm not sure I mentioned before, but it remains a DAG unless
cselib_add_permanent_equiv is called.  Only var-tracking calls it, and
even then, only when VTA is enabled, so if anyone ever runs into a
problem, it's easy enough to disable VTA, var-tracking or even -g
altogether to work around the problem.

Now, I confess I didn't expect problems in the first place, for I'd
missed this use of alias.c by var-tracking.  The other use, in
find_base_term, had been properly adjusted already.  There aren't any
other uses of CSELIB_VAL_PTR, so I'm now pretty confident we won't run
into any other problems like this.  (famous last words ;-)

> and it still isn't obvious to me when canonical_cselib_val is supposed
> to be used.

For comparison of VALUEs, it avoids the need for recursive or
combinatorial compares, for all equivalent VALUEs map directly to the
single canonical value.  For recursive searches and other the like, it's just
an optimization to avoid an additional recursion (avoiding recursing
into *any* VALUEs is recommended along with it).

Other algorithms that iterate over loc lists and recurse should take
care to avoid infinite recursion, by marking already-visited nodes
(cselib and var-tracking do some of this), temporarily zeroing out their
loc lists (like find_base_term), or using other mechanisms to break
recursion cycles (like get_addr).

Algorithms that didn't expect naked VALUEs in loc lists (like get_addr)
may need adjusting to iterate over the loc lists of the canonical value
(for non-canonical values have a single loc, the canonical value), and
to disregard values in canonical value's lists (unless e.g. we happen to
be looking for VALUEs that turn out to be noncanonical).

In other cases, the use of canonical values instead of noncanonical ones
when filling in data structures (say, building expressions to record in
cselib) may save memory by avoiding duplication, but since it causes
cselib to compute different hashes, we'd better use whatever is most
likely to be searched for by hashing.  (We could tweak lookups to use
canonical values and to recompute hashes when adding equivalences
between values already used in expressions, but this hasn't been done
yet).

I hope this makes some sense ;-)

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist      Red Hat Brazil Compiler Engineer

Reply via email to