From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from server.nextmovesoftware.com (server.nextmovesoftware.com [162.254.253.69]) by sourceware.org (Postfix) with ESMTPS id 032FB395A454 for ; Thu, 2 Jun 2022 10:55:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 032FB395A454 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=nextmovesoftware.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=nextmovesoftware.com DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nextmovesoftware.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=LaGzumPI5yaJgOKsCc4uPqXA4JrKGwFkGNYnqxwlNts=; b=rS9h9tGjAcRiq4IKJ+E7+X660Y CnejlbhUH0i2OjeMK0Wqo+t2xCdGScAywwJBIsqU2RX5Lc8lC6QUruscT0r/W82lWMhOUpmSN9GnT IyuSljYdY7/IB26TQDASoF2Hxko7+DimMRwsxcPaZwU/CnOXvW5pBdH5ijkCFaR1jkK7BNGDMSxq2 IoZIqCnjgFkSoKWY8UHyT8hitN7PA8+iD6C20pUu6G4xVwrZkaCTUwszkUxY/lmVSSpjQQ6HftBFq uroy4tnDkjg8sw15830XNUHo4vbhVSdoR9nkae2iz65Qezm9zfC3YnP1WXLp9uLXMs5LFuzrxDk5d y214SB8Q==; Received: from host109-154-46-241.range109-154.btcentralplus.com ([109.154.46.241]:56184 helo=Dell) by server.nextmovesoftware.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nwiTu-0006Ul-Ap; Thu, 02 Jun 2022 06:55:10 -0400 From: "Roger Sayle" To: "'Richard Biener'" Cc: "'GCC Patches'" References: <020201d87420$1e944a80$5bbcdf80$@nextmovesoftware.com> In-Reply-To: Subject: RE: [PATCH] Fold truncations of left shifts in match.pd Date: Thu, 2 Jun 2022 11:55:08 +0100 Message-ID: <03e201d8766f$3a597be0$af0c73a0$@nextmovesoftware.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFRBMsuSN7MvomhbuxDCc93jGtqIQF43eXMrj8GdvA= Content-Language: en-gb X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.nextmovesoftware.com X-AntiAbuse: Original Domain - gcc.gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nextmovesoftware.com X-Get-Message-Sender-Via: server.nextmovesoftware.com: authenticated_id: roger@nextmovesoftware.com X-Authenticated-Sender: server.nextmovesoftware.com: roger@nextmovesoftware.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Status: No, score=-6.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2022 10:55:12 -0000 Hi Richard, > + /* RTL expansion knows how to expand rotates using shift/or. */ = if > + (icode =3D=3D CODE_FOR_nothing > + && (code =3D=3D LROTATE_EXPR || code =3D=3D RROTATE_EXPR) > + && optab_handler (ior_optab, vec_mode) !=3D CODE_FOR_nothing > + && optab_handler (ashl_optab, vec_mode) !=3D CODE_FOR_nothing) > + icode =3D (int) optab_handler (lshr_optab, vec_mode); >=20 > but we then get the vector costing wrong.=20 The issue is that we currently get the (relative) vector costing wrong. Currently for gcc.dg/vect/pr98674.c, the vectorizer thinks the scalar code requires two shifts and an ior, so believes its profitable to = vectorize this loop using two vector shifts and an vector ior. But once match.pd simplifies the truncate and recognizes the HImode rotate we end up with: pr98674.c:6:16: note: =3D=3D> examining statement: _6 =3D _1 r>> 8; pr98674.c:6:16: note: vect_is_simple_use: vectype vector(8) short int pr98674.c:6:16: note: vect_is_simple_use: operand 8, type of def: = constant pr98674.c:6:16: missed: op not supported by target. pr98674.c:8:33: missed: not vectorized: relevant stmt not supported: = _6 =3D _1 r>> 8; pr98674.c:6:16: missed: bad operation or unsupported loop bound. Clearly, it's a win to vectorize HImode rotates, when the backend can = perform 8 (or 16) rotations at a time, but using 3 vector instructions, even = when a scalar rotate can performed in a single instruction. Fundamentally, = vectorization may still be desirable/profitable even when the backend doesn't provide an = optab. The current situation where the i386's backend provides expanders to = lower rotations (or vcond) into individual instruction sequences, also = interferes with vector costing. It's the vector cost function that needs to be fixed, = not the generated code made worse (or the backend bloated performing its own RTL expansion workarounds). Is it instead ok to mark pr98674.c as XFAIL (a regression)? The tweak to tree-vect-stmts.cc was based on the assumption that we = wished to continue vectorizing this loop. Improving scalar code generation = really shouldn't disable vectorization like this. Cheers, Roger --