This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Division Optimization in match and simplify
- From: Marc Glisse <marc dot glisse at inria dot fr>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, "Hurugalawadi, Naveen" <Naveen dot Hurugalawadi at caviumnetworks dot com>
- Date: Wed, 4 Nov 2015 13:45:49 +0100 (CET)
- Subject: Re: Division Optimization in match and simplify
- Authentication-results: sourceware.org; auth=none
- References: <BLUPR0701MB10112FDAF6046909BE252FFB8E2A0 at BLUPR0701MB1011 dot namprd07 dot prod dot outlook dot com> <alpine dot DEB dot 2 dot 20 dot 1511040920400 dot 2317 at laptop-mg dot saclay dot inria dot fr> <BLUPR0701MB10110152D9B362818EB337668E2A0 at BLUPR0701MB1011 dot namprd07 dot prod dot outlook dot com> <alpine dot DEB dot 2 dot 20 dot 1511041155570 dot 2317 at laptop-mg dot saclay dot inria dot fr> <CAFiYyc172oRzH6H8dNP0E5mbEcN5GVGF1ujoWtUvDUV0TBQkcw at mail dot gmail dot com>
- Reply-to: gcc-patches at gcc dot gnu dot org
On Wed, 4 Nov 2015, Richard Biener wrote:
I don't really remember what the tests !TYPE_UNSIGNED (type) and
tree_int_cst_sgn are for in the other pattern, but since you are only moving
the transformation...
+/* Optimize (X & (-A)) / A where A is a power of 2, to X >> log2(A) */
+(for div (exact_div trunc_div)
+ (simplify
+ (div (bit_and @0 INTEGER_CST@1) INTEGER_CST@2)
+ (if (!TYPE_UNSIGNED (type) && integer_pow2p (@2)
+ && tree_int_cst_sgn (@2) > 0
+ && wi::add (@2, @1) == 0)
+ (rshift @0 { build_int_cst (integer_type_node, wi::exact_log2 (@2)); }))))
the TYPE_UNSIGNED test is because right shift of negative values is undefined,
tree.def: "Shift means logical shift if done on an unsigned type, arithmetic shift if done on a signed type."
To me, this implies that right shift of negative values is well-defined
inside gcc.
Also, the test allows *only signed types*, not unsigned.
so is a shift with a negative value. I believe we can safely handle
conversions here
just like fold-const.c does with
(div (convert? (bit_and @0 INTEGER_CST@1) INTEGER_CST@2)
(if (tree_nop_conversion_p (type, TREE_TYPE (@0)))
...
With that the pattern looks ok to me.
As long as it comes with (convert @0) in the result... I think the
fold-const.c pattern is lucky that (int)(x&-4u) gets folded to
(int)x&-4, or it might ICE for ((int)(x&-4u))/4.
--
Marc Glisse