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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #2) 
> Match pattern:
> ```
> (for bitop (bit_ior bit_and)
>      cmp1  (eq      ne     )
>      cmp2  (ne      eq     )
>  (simplify
>   (bitop:c
>    (cmp1 @1 integer_zerop)
>    (cmp2 (bit_ior:c @0 @1) integer_zerop))
>   { constant_boolean_node (bitop == BIT_IOR_EXPR, type); }))
> ```

But this breaks generic-match building of the function:
tree
generic_simplify_92 (location_t ARG_UNUSED (loc), const tree ARG_UNUSED (type),
 tree ARG_UNUSED (_p0), tree ARG_UNUSED (_p1), tree *captures,
 const enum tree_code ARG_UNUSED (bitop),
 const enum tree_code ARG_UNUSED (cmp1),
 const enum tree_code ARG_UNUSED (cmp2))
{
  const bool debug_dump = dump_file && (dump_flags & TDF_FOLDING);
  if (TREE_SIDE_EFFECTS (_p0)) goto next_after_fail192;
  if (TREE_SIDE_EFFECTS (_p1)) goto next_after_fail192;
  if (UNLIKELY (!dbg_cnt (match))) goto next_after_fail192;
  {
    tree _r;
    _r =  constant_boolean_node (bitop == BIT_IOR_EXPR, type);
    if (UNLIKELY (debug_dump)) generic_dump_logs ("match.pd", 136, __FILE__,
__LINE__, true);
    return _r;
  }
next_after_fail192:;
  return NULL_TREE;
}


captures is not used .

I guess I could check TREE_SIDE_EFFECTS on @0/@1 to workaround that issue.

Like so:
```
(for bitop (bit_ior bit_and)
     cmp1  (eq      ne     )
     cmp2  (ne      eq     )
 (simplify
  (bitop:c
   (cmp1 @1 integer_zerop)
   (cmp2 (bit_ior:c @0 @1) integer_zerop))
  (if (GIMPLE || (!TREE_SIDE_EFFECTS (@0)
                   && !TREE_SIDE_EFFECTS (@1)))
   { constant_boolean_node (bitop == BIT_IOR_EXPR, type); })))
```

I had assumed genmatch would generate that code that would use @0/@1 if they
had side effects.  Maybe because I match @0 twice, it assumed we would be using
the captures (I have not looked though).

Reply via email to