https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119614
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I see.
<bb 48> [local count: 138047908]:
_231 = MEM[(short unsigned int *)table_49(D)];
google::protobuf::internal::TcParser::Error.constprop.isra (msg_55(D), _231,
hasbits_67(D)); [must tail call]
goto <bb 83>; [100.00%]
...
<bb 83> [local count: 138047908]:
<bb 84> [local count: 1073737840]:
# _35 = PHI <_89(5), 0B(83), _141(78), ptr_31(69), ptr_32(72)>
return _35;
If the lhs is missing, we currently compare the singleton value range constant
against ret_var.
That works if it returns that constant, but not if it returns result of PHI
which has that constant on an edge.
So I guess we'd need to walk the bbs backwards to the call bb, if ret_var is a
PHI, find the PHI argument from the edge until we get the singleton constant.
Another (but perhaps just theoretical issue) is that
/* Propagate VAR through phis on edge E. */
static tree
propagate_through_phis (tree var, edge e)
{
basic_block dest = e->dest;
gphi_iterator gsi;
for (gsi = gsi_start_phis (dest); !gsi_end_p (gsi); gsi_next (&gsi))
{
gphi *phi = gsi.phi ();
if (PHI_ARG_DEF_FROM_EDGE (phi, e) == var)
return PHI_RESULT (phi);
}
return var;
}
picks up the first PHI with var as argument. What if there are multiple PHIs
with var as argument from that edge, but only the second or later is what
actually propagates to the ret_var? Though, one has to wonder what would the
other PHI used for...
