On Thu, Oct 10, 2013 at 5:04 AM, Jeff Law <l...@redhat.com> wrote: > On 08/05/13 02:08, Zhenqiang Chen wrote: >> >> Hi >> >> The patch reassociates X == CST1 || X == CST2 if popcount (CST2 - CST1) == >> 1 >> into ((X - CST1) & ~(CST2 - CST1)) == 0. >> >> Bootstrap on x86-64 and ARM chromebook. >> No make check regression on x86-64 and panda board. >> >> For some targets/options, the "(X == CST1 || X == CST2)" might be >> converted >> to "if (x == CST1) else if (x == CST2)" at the beginning. In such case, >> the >> patch will not be executed. It is hard to write a reliable testcase to >> detect the transformation. So the testcase does not check the dump logs >> from >> reassoc1 pass. It just checks the runtime result. >> >> Is it OK for trunk? >> >> Thanks! >> -Zhenqiang >> >> ChangeLog >> 2013-08-05 Zhenqiang Chen <zhenqiang.c...@arm.com> >> >> * tree-ssa-reassoc.c (optimize_range_tests): Reasociate >> X == CST1 || X == CST2 if popcount (CST2 - CST1) == 1 into >> ((X - CST1) & ~(CST2 - CST1)) == 0. >> >> testsuite/ChangeLog >> 2013-08-05 Zhenqiang Chen <zhenqiang.c...@arm.com> >> >> * gcc.dg/reassoc1.c: New testcase. > > This is an interesting transformation. I suspect we'd want to gate it on > something like BRANCH_COST. For a related example, see how we handle (a != > 0) || (b != 0) -> (a | b) != 0 in fold-const.c. I suspect the conditions > under which we want to do your transformation are going to be similar if not > the same as those transformations in fold-const.c. > > Note I've been suggesting the bits I'm referring to in fold-const.c move out > into the tree-ssa optimizers. If they fit well into tree-ssa-reassoc.c I'd > look favorably upon a patch which moved them.
In particular I strongly vote against putting more target dependent transformations into fold-const.c. Richard. > As far as testing, the way to go will be to look at the reassoc1 dumps, but > skip the test on targets with the "wrong" branch cost. tree-ssa/vrp87.c has > a suitable condition to filter out the test on targets were the branch cost > is too small. > > Out of curiosity, what prompted you to make this transformation? Was it > mostly to deal with a codesize problem or is it a significant win on some > hot code in a benchmark, or something else? Closely related, have you done > anything like instrument the transformation to see how often it applies > during a GCC bootstrap? > > jeff > >