This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Simple bitop reassoc in match.pd (was: Canonicalize X u< X to UNORDERED_EXPR)
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Marc Glisse <marc dot glisse at inria dot fr>
- Cc: Richard Biener <richard dot guenther at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 11 May 2016 06:52:04 -0700
- Subject: Re: Simple bitop reassoc in match.pd (was: Canonicalize X u< X to UNORDERED_EXPR)
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 02 dot 1604302026470 dot 16157 at laptop-mg dot saclay dot inria dot fr> <CAFiYyc2xujT_wU426OFn7+UPuMdm-=5_n9wqA-E5quefG3pUJA at mail dot gmail dot com> <alpine dot DEB dot 2 dot 20 dot 1605021043250 dot 1830 at laptop-mg dot saclay dot inria dot fr> <CAFiYyc0xAovn2-X44Zp4uU432UkF-jUcrrOQYxE-3PV+qiHDxA at mail dot gmail dot com> <alpine dot DEB dot 2 dot 02 dot 1605022320550 dot 23827 at laptop-mg dot saclay dot inria dot fr> <CAFiYyc0yc-Svq0=6Okk8hb9TP2hb6R-PARU8PSFf-ttDKRSwsQ at mail dot gmail dot com> <alpine dot DEB dot 2 dot 20 dot 1605031435510 dot 1905 at laptop-mg dot saclay dot inria dot fr> <CAFiYyc3A3jJvGKONB+mmSrpkunQgOv=+GjAQjcEdbyRY-zbhnQ at mail dot gmail dot com> <alpine dot DEB dot 2 dot 02 dot 1605061313400 dot 19107 at laptop-mg dot saclay dot inria dot fr> <alpine dot DEB dot 2 dot 02 dot 1605100810480 dot 7805 at laptop-mg dot saclay dot inria dot fr>
On Mon, May 9, 2016 at 11:11 PM, Marc Glisse <marc.glisse@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.glisse@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.