https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80960
--- Comment #19 from Segher Boessenkool <segher at gcc dot gnu.org> --- (In reply to rguent...@suse.de from comment #18) > Hmm, so if we'd have numbered stmts in an EBB we could check the > distance between set and use and not combine when that gets too big? Yeah. Or we could even not make a LOG_LINK in the first place between statements that are too far apart. > > Combine also makes garbage for every try, and none of that is cleaned > > up during combine. Maybe we should change that? (I can try next week). > > Not sure how easy that is but yes, it might help quite a bit due > to less churn on the cache. Just ggc_free()ing the "toplevel" > RTX of failed attempts might already help a bit. It's of course > kind-of a hack then but with an appropriate comment it would be > fine I guess (recursively ggc_free()ing might run into sharing > issues so that probably won't work). combine does not change anything *between* combination attempts, and all attempts go via the same function (try_combine), so calling gcc_collect should be fine. Manually gcc_free'ing things would be a hack alright.
