This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tree-optimization/80198] [6/7 Regression] does not vectorize generic inplace integer operation


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80198

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
How would building equivalences help?
Looking at the gcc.dg/tree-ssa/20030922-2.c testcase, the reason it works with
Jeff's patch is that we are lucky enough on that exact testcase starting with:
  if (_6 != _11)
    goto <bb 3>; [69.50%]
  else
    goto <bb 6>; [30.50%]

  <bb 3> [69.50%]:
  target_bb.3_12 = target_bb;
  if (_11 == target_bb.3_12)
    goto <bb 4>; [37.68%]
  else
    goto <bb 6>; [62.32%]

  <bb 4> [26.19%]:
  if (_6 != target_bb.3_12)
and first replace the target_bb.3_12 due to the extra added SSA_NAME_VALUE to
_11 in the last GIMPLE_COND above during cprop_operand and then
eliminate_redundant_computations do
avail_exprs_stack->lookup_avail_expr (stmt, insert, true);
on that if (_6 != _11) and find it.  If we are unlucky enough and say have
  if (_6 != _11)
in the bb4 and replace that with if (_6 != target_bb.3_12), then we won't find
it.  Consider say -O1 -fno-tree-fre:
struct rtx_def;
typedef struct rtx_def *rtx;
struct rtx_def
{
  int bb;
};
int *block_to_bb;
int target_bb;

int
rgn_rank (rtx insn1, rtx insn2)
{
  int a = block_to_bb[insn1->bb];
  int b = block_to_bb[insn2->bb];
  if (a != b)
    if (b == target_bb && a != b)
      return 1;
}
Here dom2 with the r233207 change reverted is optimized into just two
GIMPLE_CONDs, while current trunk does not (manages to do it only during dom3).
As the first if (_6 != _11) is entered before we have any equivalences recorded
(and the equivalences are only temporary anyway, might not be in effect in all
the places where the if (_6 != _11) is in effect), I think there is no hope for
some canonicalization of the stmt we want to look up at the place we have some
equivalences for it temporarily recorded can help in doing just a single hash
table lookup.
Perhaps we should revert r233207 and in addition to the SSA_NAME_VALUE record
the temporary equivalences some way in another data structure (e.g. forward and
backward chains to other SSA_NAME versions, chains could be just unsigned int
SSA_NAME_VERSIONs or whatever).  Then e.g.
avail_exprs_stack::lookup_avail_expr
if it detects one or both arguments of the stmt have temporary equivalences
recorded could just loop through all the equivalence combinations (perhaps with
some upper bound), trying to (!insert) find the available expression.  And if
everything else fails do the insert lookup (if requested) on the SSA_NAMEs as
in the stmt last.  Thoughts on this?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]