This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Reassociate X == CST1 || X == CST2 if popcount (CST2 - CST1) == 1 into ((X - CST1) & ~(CST2 - CST1)) == 0
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Zhenqiang Chen <zhenqiang dot chen at arm dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 10 Oct 2013 09:58:07 +0200
- Subject: Re: [PATCH] Reassociate X == CST1 || X == CST2 if popcount (CST2 - CST1) == 1 into ((X - CST1) & ~(CST2 - CST1)) == 0
- Authentication-results: sourceware.org; auth=none
- References: <000001ce91b3$0a947cc0$1fbd7640$ at arm dot com> <52561947 dot 90600 at redhat dot com>
On Thu, Oct 10, 2013 at 5:04 AM, Jeff Law <law@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.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.
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
>
>