https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121792
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Summary|missing PRE due to |missing PRE due to
|exceptions |exceptions, partial PRE
| |insertion too restricted
Last reconfirmed| |2025-09-05
CC| |rguenth at gcc dot gnu.org
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Well, it's not a missing PRE - it's how PRE works. The load from pid.t is only
a partial redundancy on the path from get_pid () if it is actually loaded, but
it isn't on the EH edge from kill_pid (0), putting it before kill_pid (0) would
load it when it wasn't before. So this isn't PRE. It's partial PRE:
PA_IN[5] := { {component_ref<t>,mem_ref<0B>,addr_expr<&pid>}@.MEM_10 (0012),
{component_ref<value>,mem_ref<0B>,addr_expr<&pid>}@.MEM_10 (0010) }
avail_out[16] := { is_running.0_1 (0001) }
avail_out[4] := { is_running.0_1 (0001) }
and I don't see how PHI translation can get to an available value on 16->5
where we only have
pid = get_pid ();
so our partial-PRE restriction that it only inserts for partially anticipated
but fully available expressions rejects this opportunity.
Confirmed for the partial PRE opportunity (but it behaves like it was designed
to).
