https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125501
--- Comment #17 from Andrew Macleod <amacleod at redhat dot com> ---
Yes, our comments collided, but I was writing this while ytou were writing
yours :-)
Thinking about it a bit more, I'm not sure the relation check is sufficient.
IN this program, the only relation between a4_14 and a5_16 is the condition
that feeds the builtin_unreachable(). So a query for relations would find
none at any use point,
its the relation into the builtin that is causing the problem..
Its being compared to a4_14.. and any relation query for a4_14 will come up
empty as well because its never compared to an SSA_NAME, only 0.
Looking at VRP's handling of it, I missed this:
void
remove_unreachable::handle_early (gimple *s, edge e)
{
// If there is no gori_ssa, there is no early processsing.
if (!m_ranger.gori_ssa ())
return ;
bool lhs_p = TREE_CODE (gimple_cond_lhs (s)) == SSA_NAME;
bool rhs_p = TREE_CODE (gimple_cond_rhs (s)) == SSA_NAME;
// Do not remove __builtin_unreachable if it confers a relation, or
// that relation may be lost in subsequent passes.
if (lhs_p && rhs_p)
return;
It refuses to create a global value before VRP2 for any builtin_unreachable()
that is reached by a an expression which produces a relation... Thus avoiding
this scenario... and acting like the equivalent of "is a5_16 related to an
SSA_NAME anywhere in the program.
DOM could do that as well....
