[Bug tree-optimization/66948] [6 Regression] Performance regression in bit manipulation code

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2015-07-21
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org
   Target Milestone|---                         |6.0
            Summary|Performance regression in   |[6 Regression] Performance
                   |bit manipulation code       |regression in bit
                   |                            |manipulation code
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Possibly

/* Fold (X & C2) << C1 into (X << C1) & (C2 << C1)
   (X & C2) >> C1 into (X >> C1) & (C2 >> C1).  */
(for shift (lshift rshift)
 (simplify
  (shift (convert? (bit_and @0 INTEGER_CST@2)) INTEGER_CST@1)
  (if (tree_nop_conversion_p (type, TREE_TYPE (@0)))
   (with { tree mask = int_const_binop (shift, fold_convert (type, @2), @1); }
    (bit_and (shift (convert @0) @1) { mask; })))))

which in the fold-const.c variant was conditonalized on

"if the latter can be further optimized."

which cannot be expressed in a useful way in match.pd language.  Adding
single-use markers doesn't help, disabling the pattern does.  On my machine
the difference isn't that big - 6.9s vs 6.4s.

The .optimized dump shows a lot more operations in trunk compared to GCC 5.

Note the above pattern catches for example (v & 1431655765) >> 1

  v = v & 1431655765;
  v = (v >> 1 | v) & 858993459;

Ah, I see an issue.  Mine.