https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117954
--- Comment #5 from rguenther at suse dot de <rguenther at suse dot de> --- On Sun, 8 Dec 2024, pinskia at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117954 > > Andrew Pinski <pinskia at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Last reconfirmed| |2024-12-08 > Target Milestone|--- |15.0 > Status|UNCONFIRMED |NEW > Ever confirmed|0 |1 > > --- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> --- > Confirmed. > > This is a missing PRE (in the same area as I was changing recently). There isn't a missed PRE - the load of 'i' in the latch isn't partially redundant as it isn't performed on the loop exit. It's partial-partial redundant on loop entry, but do_pre_partial_partial_insertion refuses to insert there because of /* Insert only if we can remove a later expression on a path that we want to optimize for speed. The phi node that we will be inserting in BLOCK is not free, and inserting it for the sake of !optimize_for_speed successor may cause regressions on the speed path. */ FOR_EACH_EDGE (succ, ei, block->succs) { if (bitmap_set_contains_value (PA_IN (succ->dest), val) || bitmap_set_contains_value (ANTIC_IN (succ->dest), val)) { if (optimize_edge_for_speed_p (succ)) do_insertion = true; } } and the 67% edge 10 -> 19 where the value is PA_IN (the block w/o the call) isn't an edge we optimize for speed(?). Skipping partial partial redundancy for expression {mem_ref<0B>,addr_expr<&i>}@.MEM_12 (0020), not (partially) anticipated on any to be optimized for speed edges It's a bit odd we check successor edges here - the edges checked are effectively quite random. The check was added by r0-116480-gfa06ad0d58e898. It might be useful to track this in a separate PR. But as said, fixing won't help -O2.
