From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 126010 invoked by alias); 13 Jan 2020 18:06:00 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 126000 invoked by uid 89); 13 Jan 2020 18:06:00 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=fes, HX-Languages-Length:2330, H*f:sk:AM5PR08, H*i:sk:AM5PR08 X-HELO: us-smtp-delivery-1.mimecast.com Received: from us-smtp-1.mimecast.com (HELO us-smtp-delivery-1.mimecast.com) (205.139.110.61) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 13 Jan 2020 18:05:59 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1578938757; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=FSc4MKGGGoklKdqeCx1AHJruKXen5nis+JGKEB1ytsc=; b=FJGFsglvRT+PK14DMcAECyXHpob3d5Ro70UR1TEOa4OeKQrN+w1t9nq8773ouYHDDl2XGk CYQZ1RaOeKJa843bLwMnYTzGsHsKe1Y+I/6KHHm9UaRDA7VYrqBWT7NNcOGbRRgZpx43Na N7tEp3cuLgiqebtwByE89piJGZY8/UY= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-220-fhomXEY_PWiiHFz3GjSa2Q-1; Mon, 13 Jan 2020 13:05:55 -0500 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id DE4A7800D41; Mon, 13 Jan 2020 18:05:54 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-116-112.ams2.redhat.com [10.36.116.112]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 76BDF19C70; Mon, 13 Jan 2020 18:05:54 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id 00DI5qef000374; Mon, 13 Jan 2020 19:05:52 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id 00DI5pTQ000373; Mon, 13 Jan 2020 19:05:51 +0100 Date: Mon, 13 Jan 2020 18:16:00 -0000 From: Jakub Jelinek To: Wilco Dijkstra Cc: GCC Patches Subject: Re: [PATCH] Fix ctz issues (PR93231) Message-ID: <20200113180550.GT10088@tucnak> Reply-To: Jakub Jelinek References: MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.11.3 (2019-02-01) X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-IsSubscribed: yes X-SW-Source: 2020-01/txt/msg00738.txt.bz2 On Mon, Jan 13, 2020 at 05:30:23PM +0000, Wilco Dijkstra wrote: > Further improve the ctz recognition: Avoid ICEing on negative shift > counts or multiply constants. Check the type is 8 bits for the string > constant case to avoid accidentally matching a wide STRING_CST. > Add a tree_expr_nonzero_p check to allow the optimization even if > CTZ_DEFINED_VALUE_AT_ZERO returns 0 or 1. Add extra test cases. >=20 > (note the diff uses the old tree and includes Jakub's bootstrap fixes) You should rebase it because you'll be committing it against trunk which already has those changes. > @@ -1879,7 +1879,7 @@ optimize_count_trailing_zeroes (tree array_ref, tre= e x, tree mulc, > if (!low || !integer_zerop (low)) > return false; >=20=20 > - unsigned shiftval =3D tree_to_uhwi (tshift); > + unsigned shiftval =3D tree_to_shwi (tshift); This relies on the FEs to narrow the type of say: x >> (((__uint128_t) 0x12 << 64) | 0x1234567812345678ULL) > @@ -1889,12 +1889,13 @@ optimize_count_trailing_zeroes (tree array_ref, t= ree x, tree mulc, > if (!ctor) > return false; >=20=20 > - unsigned HOST_WIDE_INT val =3D tree_to_uhwi (mulc); > + /* Extract the binary representation of the multiply constant. */ > + unsigned HOST_WIDE_INT val =3D TREE_INT_CST_LOW (mulc); Will it work properly with the signed types though? The difference is whether the C code we are matching will use logical or arithmetic right shift. And if the power of two times mulc ever can have sign bit set, it will then use negative indexes into the array. > - if (TREE_CODE (ctor) =3D=3D STRING_CST) > + if (TREE_CODE (ctor) =3D=3D STRING_CST && TYPE_PRECISION (type) =3D=3D= 8) Isn't another precondition that BITS_PER_UNIT is 8 (because STRING_CSTs are really bytes)? > return check_ctz_string (ctor, val, zero_val, shiftval, input_bits); >=20=20 > return false; > @@ -1920,15 +1921,24 @@ simplify_count_trailing_zeroes (gimple_stmt_itera= tor *gsi) > res_ops[1], res_ops[2], zero_val)) > { > tree type =3D TREE_TYPE (res_ops[0]); > - HOST_WIDE_INT ctzval; > + HOST_WIDE_INT ctz_val =3D 0; > HOST_WIDE_INT type_size =3D tree_to_shwi (TYPE_SIZE (type)); > - bool zero_ok =3D CTZ_DEFINED_VALUE_AT_ZERO (TYPE_MODE (type), ctzv= al) =3D=3D 2; > + bool zero_ok =3D > + CTZ_DEFINED_VALUE_AT_ZERO (SCALAR_INT_TYPE_MODE (type), ctz_val) =3D=3D= 2; =3D shouldn't be at the end of line. Jakub