https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113080
Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Last reconfirmed| |2023-12-19 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> --- Confirmed. We're considering the final value replacement of the 't' reduction expensive. It's ((b_lsm.10_8 + a_lsm.9_9) + t_10(D)) + (b_lsm.10_8 + a_lsm.9_9) * 99 and since there's a shared tree (b_lsm.10_8 + a_lsm.9_9) which we'd duplicate (materializing as GIMPLE fails to immediately CSE). bool expression_expensive_p (tree expr, bool *cond_overflow_p) { hash_map<tree, uint64_t> cache; uint64_t expanded_size = 0; *cond_overflow_p = false; return (expression_expensive_p (expr, cond_overflow_p, cache, expanded_size) || expanded_size > cache.elements ()); } where expanded_size is 5 but cache.elements () is 4 (we grow because of unsharing). Allowing a little bit of unsharing fixes this. Even better would be of course an unsharing mechanism that would "save" the shared parts to a gimple sequence (we need to unshare because gimplification is destructive and the SCEV result contains trees that can be part of the SCEV cache which we may not alter).