From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 51889 invoked by alias); 24 Apr 2017 08:02:45 -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 51867 invoked by uid 89); 24 Apr 2017 08:02:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-12.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*RU:74.125.82.65, Hx-spam-relays-external:74.125.82.65, love, thousands X-HELO: mail-wm0-f65.google.com Received: from mail-wm0-f65.google.com (HELO mail-wm0-f65.google.com) (74.125.82.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 24 Apr 2017 08:02:42 +0000 Received: by mail-wm0-f65.google.com with SMTP id z129so15344198wmb.1 for ; Mon, 24 Apr 2017 01:02:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:subject:date:user-agent:cc :references:in-reply-to:mime-version:content-transfer-encoding :message-id; bh=+BtoZ3em+yHYGp0QQ78RmI6rKA/VTh344x+9oLLOue8=; b=mZkUvsgOHbpCFR3ChuEjpEs2AtroLmJx5ftxxTGftHftK5DFZDP0PX4Y9zuW87TZOV 8SLJw5Md+0h2i4rzh7h9buPXwZ415jMiT9py63YcJRfnP8PiqDZUAzJWc+pDh2+3D7Bk seZTKCN4SMLmb3UEtELmMowG7Ghgr5NMqlOhcmQG8hCBG08UBWw8b0c+rPVmY3OTUkKX MsMfm/dr7BGqieo0Vn6yOHp7+2YHDmvOOh/bbNeboyFuDRQ6/LRqGPFo6D2DmWJOhhW8 pLUM98GgTD4JjgLcyuXouOPcX+8oxLiAJf52XBiI6bx6BqahkPSNX8iKLQWqBo3NIpFK WoMw== X-Gm-Message-State: AN3rC/64BrpYxM7HWyf31FzNwQ9Msn8mfGUVcSdZ9wAEGll+mxp9InAU Y2V5+KZH44RW1Q== X-Received: by 10.28.27.134 with SMTP id b128mr8563950wmb.67.1493020962321; Mon, 24 Apr 2017 01:02:42 -0700 (PDT) Received: from princessluna.localnet (p4FE41D98.dip0.t-ipconnect.de. [79.228.29.152]) by smtp.gmail.com with ESMTPSA id o189sm11778903wmg.32.2017.04.24.01.02.41 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 24 Apr 2017 01:02:41 -0700 (PDT) From: Allan Sandfeld Jensen To: gcc-patches@gcc.gnu.org, Jakub Jelinek Subject: Re: [PATCH] [x86] Avoid builtins for SSE/AVX2 immidiate logical shifts Date: Mon, 24 Apr 2017 08:25:00 -0000 User-Agent: KMail/1.13.7 (Linux/4.9.0-2-amd64; KDE/4.14.27; x86_64; ; ) Cc: Uros Bizjak References: <201704221338.46300.linux@carewolf.com> <201704240951.29932.linux@carewolf.com> <20170424075627.GI1809@tucnak> In-Reply-To: <20170424075627.GI1809@tucnak> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201704241002.40719.linux@carewolf.com> X-IsSubscribed: yes X-SW-Source: 2017-04/txt/msg01003.txt.bz2 On Monday 24 April 2017, Jakub Jelinek wrote: > On Mon, Apr 24, 2017 at 09:51:29AM +0200, Allan Sandfeld Jensen wrote: > > On Monday 24 April 2017, Jakub Jelinek wrote: > > > On Mon, Apr 24, 2017 at 09:33:09AM +0200, Allan Sandfeld Jensen wrote: > > > > --- a/gcc/config/i386/avx2intrin.h > > > > +++ b/gcc/config/i386/avx2intrin.h > > > > @@ -667,7 +667,7 @@ extern __inline __m256i > > > > > > > > __attribute__ ((__gnu_inline__, __always_inline__, __artificial__)) > > > > _mm256_slli_epi16 (__m256i __A, int __B) > > > > { > > > > > > > > - return (__m256i)__builtin_ia32_psllwi256 ((__v16hi)__A, __B); > > > > + return ((__B & 0xff) < 16) ? (__m256i)((__v16hi)__A << (__B & > > > > 0xff)) : _mm256_setzero_si256(); > > > > > > > > } > > > > > > What is the advantage of doing that when you replace one operation with > > > several (&, <, ?:, <<)? > > > I'd say instead we should fold the builtins if in the gimple fold > > > target hook we see the shift count constant and can decide based on > > > that. Or we could use __builtin_constant_p (__B) to decide whether to > > > use the generic vector shifts or builtin, but that means larger IL. > > > > The advantage is that in this builtin, the __B is always a literal (or > > constexpr), so the if statement is resolved at compile time. > > Do we really want to support all the thousands _mm* intrinsics in constexpr > contexts? People can just use generic vectors instead. > I would love to support it, but first we need a C extension attribute matching constexpr, and I consider it a separate issue. > That said, both the options I've mentioned above provide the same > advantages and don't have the disadvantages of pessimizing normal code. > What pessimizing? This produce the same or better code for all legal arguments. The only difference besides better generated code is that it allows the intrinsics to be used incorrectly with non-literal arguments because we lack the C-extension for constexp to prevent that. `Allan