On Mon, May 9, 2016 at 11:11 PM, Marc Glisse <marc.gli...@inria.fr> wrote: > On Fri, 6 May 2016, Marc Glisse wrote: > >> Here they are. I did (X&Y)&X and (X&Y)&(X&Z). The next one would be >> ((X&Y)&Z)&X, but at some point we have to defer to reassoc. >> >> I didn't add the convert?+tree_nop_conversion_p to the existing transform >> I modified. I guess at some point we should make a pass and add them to all >> the transformations on bit operations... >> >> For (X & Y) & Y, I believe that any conversion is fine. For the others, >> tree_nop_conversion_p is probably too strict (narrowing should be fine for >> all), but I was too lazy to look for tighter conditions. >> >> (X ^ Y) ^ Y -> X should probably have (non_lvalue ...) on its output, but >> in a simple test it didn't seem to matter. Is non_lvalue still needed? >> >> >> Bootstrap+regtest on powerpc64le-unknown-linux-gnu. >> >> 2016-05-06 Marc Glisse <marc.gli...@inria.fr> >> >> gcc/ >> * fold-const.c (fold_binary_loc) [(X ^ Y) & Y]: Remove and merge >> with... >> * match.pd ((X & Y) ^ Y): ... this. >> ((X & Y) & Y, (X | Y) | Y, (X ^ Y) ^ Y, (X & Y) & (X & Z), (X | Y) >> | (X | Z), (X ^ Y) ^ (X ^ Z)): New transformations. >> >> gcc/testsuite/ >> * gcc.dg/tree-ssa/bit-assoc.c: New testcase. >> * gcc.dg/tree-ssa/pr69270.c: Adjust. >> * gcc.dg/tree-ssa/vrp59.c: Disable forwprop. > > > Here it is again, I just replaced convert with convert[12] in the last 2 > transforms. This should matter for (unsigned)(si & 42) & (ui & 42u). I > didn't change it in the other transform, because it would only matter in the > case (T)(X & CST) & CST, which I think would be better served by extending > the transform that currently handles (X & CST1) & CST2 (not done in this > patch).
It caused: FAIL: gcc.dg/tree-ssa/vrp47.c scan-tree-dump-times vrp2 " & 1;" 0 on x86. H.J.
