https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115494
--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
It is somewhat of a representational issue given we translate dependend
expressions using leaders in the translated set but the expression sets
contain the original defs (which would have been pruned if there were no
leader for their value).
ANTIC_IN[5] has {bit_not_expr,_16} (0016), {bit_ior_expr,_5,_19} (0017)
vs. ANTIC_IN[6] {bit_not_expr,_16} (0016), {bit_ior_expr,_5,_17} (0017)
so the idea to always assign those dependent ops new names does address
this issue. pre_valueize should to some extent mitigate this, but
we are only allowing extra valueization here, we do trust existing
ops to be available which they of course are not:
static tree
pre_valueize (tree name)
{
if (TREE_CODE (name) == SSA_NAME)
{
tree tem = VN_INFO (name)->valnum;
if (tem != VN_TOP && tem != name)
{
if (TREE_CODE (tem) != SSA_NAME
|| SSA_NAME_IS_DEFAULT_DEF (tem))
return tem;
/* We create temporary SSA names for representatives that
do not have a definition (yet) but are not default defs either
assume they are fine to use. */
basic_block def_bb = gimple_bb (SSA_NAME_DEF_STMT (tem));
if (! def_bb
|| dominated_by_p (CDI_DOMINATORS, vn_context_bb, def_bb))
return tem;
/* ??? Now we could look for a leader. Ideally we'd somehow
expose RPO VN leaders and get rid of AVAIL_OUT as well... */
}
}
return name;
it is somewhat undesirable to not simplify across dependent expressions,
but get_representative would simply add a GIMPLE_NOP def which wouldn't
help here either.
The original idea was that we can stick to the original expressions for the
expression sets, but for dependent expressions we do need to allow
such "wrong" representatives to survive. But that violates the premise
that valueization starts with a valid to use op.
Creating a new SSA name as representative each time we translate a
operand might be the good fix after all, even if it looks a bit
expensive.
