[Bug tree-optimization/85758] questionable bitwise folding (missing single use check?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85758 Alexander Monakov changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Alexander Monakov --- Fixed.
[Bug tree-optimization/85758] questionable bitwise folding (missing single use check?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85758 --- Comment #3 from Alexander Monakov --- Author: amonakov Date: Mon Aug 27 14:08:50 2018 New Revision: 263887 URL: https://gcc.gnu.org/viewcvs?rev=263887=gcc=rev Log: match.pd: add single-use check for (x & y) ^ y -> ~x & y (PR 85758) PR tree-optimization/85758 * match.pd ((X & Y) ^ Y): Add :s qualifier to inner expression. Modified: trunk/gcc/ChangeLog trunk/gcc/match.pd
[Bug tree-optimization/85758] questionable bitwise folding (missing single use check?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85758 --- Comment #2 from Richard Biener --- (In reply to Alexander Monakov from comment #0) > However since m_3 is used, this is more costly. Shouldn't this folding check > for single use of the intermediate expr? From a quick look, this is probably > match.pd:/* Fold (X & Y) ^ Y and (X ^ Y) & Y as ~X & Y. */ Just as a note I'd consider ~X & Y cheaper canonicalization-wise because it has one unary and one binary op vs two binary ones. Yes, this is probably a candidate for :s With the current :s semantics :s should eventually be applied automagically by genmatch. Note that given match.pd patterns cannot rely on immediate uses being up-to-date all this is fragile heuristics anyways...
[Bug tree-optimization/85758] questionable bitwise folding (missing single use check?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85758 --- Comment #1 from Marc Glisse --- Direct translation would be (from clang): andl%ecx, %edx addl%edx, %edi xorl%ecx, %edx addl%edx, %esi With -mbmi, I get andn%ecx, %edx, %eax andl%ecx, %edx addl%eax, %esi addl%edx, %edi which is comparable to the original (andn has a longer encoding, but the operations are less dependent) We could use opi:cs in the transformation if that really helps...
