This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Reassociate X == CST1 || X == CST2 if popcount (CST2 - CST1) == 1 into ((X - CST1) & ~(CST2 - CST1)) == 0


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.chen@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.chen@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.

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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]