https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #21 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #19) > I think caching is problematic, for a couple of reasons: > 1) for non-cselib_preserved_value_p, the loc list is dynamic and keeps > changing, locs are added and removed as we go through the basic blocks Sure, but if you look at my patch I'm caching on individual locs, not on the whole list. That then still doesn't avoid traversing the whole list if we don't find a base but we'd at least elide further recursion. The base we pick also depends on the ordering of the list currently if there ever are two possible choices. > 2) because of the recursion prevention, doesn't it matter from exactly what > VALUE we start walking (in case we have a cycle or cycles)? I think the outcome is essentially random anyways since we pick the first base we find. I'm quite sure that if we collected "all" bases we'd find they are not equivalent in some cases. > 3) plus the new param on visited_vals, if we reach it, caching is unreliable Sure, but does anybody care? Note what I'd really propose would be find_base_term-local caching, eliding both the recursion prevention and the param.
