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: Marc Glisse <marc dot glisse at inria dot fr>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- 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 18:17:22 +0200 (CEST)
- 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> <CAMe9rOqKnemgoVD09do-KxE1gTcJENjZ=E3=8zu==_XkeimZFw at mail dot gmail dot com>
On Wed, 11 May 2016, H.J. Lu wrote:
* fold-const.c (fold_binary_loc) [(X ^ Y) & Y]: Remove and merge with...
* match.pd ((X & Y) ^ Y): ... this.
It caused:
FAIL: gcc.dg/tree-ssa/vrp47.c scan-tree-dump-times vrp2 " & 1;" 0
on x86.
Ah, yes, logical_op_short_circuit so I didn't test it. Hmm, doesn't seem
so easy. We want to compute (int)(x==0) in a branch where x is known to be
in [0, 1]. VRP1 gives (int)(_Bool)(x^1). forwprop3 handles the double
conversion, which gives (x^1)&1. Here the new transform applies and gives
(~x)&1. VRP2 comes, and with (x^1)&1 it used to notice that this is just
x^1 (remember that x is in [0, 1] in this branch), while it doesn't know
what to do with (~x)&1. In the end, we get
notl %eax
andl $1, %eax
instead of
xorl $1, %eax
(andn doesn't seem to have a version with an immediate)
The transformation seems right to me, but we are then missing another
transformation like ~X & Y -> X ^ Y when we know that X & ~Y is 0 (the 1
bits of X are included in those of Y). That may not be easy with the
limited bit tracking we have. A version limited to constant Y of the form
2^n-1 (i.e. 0...01...1) where X has a range included in [0, Y] may be
simpler.
We could also simplify (int)(_Bool)x to x using VRP information that x is
in [0, 1], but apparently when VRP replaces x==0 with y=x^1,(_Bool)y, it
does not compute a range for the new variable y, and by the time the next
VRP pass comes, it is too late.
In the mean time, I propose xfailing this test...
--
Marc Glisse