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).