https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103192
--- Comment #18 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #17)
> iftmp.2373_1515 is defined earlier as:
> iftmp.2373_1515 = code_1387(D) != 181 ? ctx_1386 : outer_ctx_1389;
> so the transformation by dom3? from
> if (outer_ctx_1389 != 0B)
> to
> if (iftmp.2373_1515 != 0B)
> is sound (even though it undoes some previously done optimization), but
> perhaps
> we need to reset_flow_sensitive_info on it somewhere along the way? Though,
> the definition is always not in code guarded by outer_ctx_1389 != 0B check,
> so I wonder why it would be marked as non-NULL, only the uses or some of the
> uses of the SSA_NAME can be non-NULL.
It looks like DOM uses propagate_value() which makes the substitution outright,
whereas the copy-prop pass is more careful with global ranges:
/* Points-to information is cfg insensitive,
but [E]VRP might record context sensitive alignment
info, non-nullness, etc. So reset context sensitive
info if the two SSA_NAMEs aren't defined in the same
basic block. */
if (var_bb != copy_of_bb)
reset_flow_sensitive_info (copy_of[i].value);
Perhaps we need something similar in DOM's cprop_operand?
