This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PR52001] too many cse reverse equiv exprs (take2)


Alexandre Oliva <aoliva@redhat.com> writes:
> On Feb 19, 2012, Richard Sandiford <rdsandiford@googlemail.com> wrote:
>> 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 ;-)

Yeah, it does, thanks.  It seemed that when we recorded two values V1
and V2 were equivalent, we added V1 to V2's location list and V2 to V1's
location list.  But it sounds from the above like the canonical value is
what we want in almost all cases, so if V2 is the one that becomes
"noncanonical", is it really worth adding V2 to V1's location list?

Richard


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]