From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18634 invoked by alias); 24 Apr 2017 08:26:01 -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 18227 invoked by uid 89); 24 Apr 2017 08:25:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 24 Apr 2017 08:25:57 +0000 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9557F15567; Mon, 24 Apr 2017 08:25:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 9557F15567 Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jakub@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 9557F15567 Received: from tucnak.zalov.cz (ovpn-116-29.ams2.redhat.com [10.36.116.29]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3EBD07A410; Mon, 24 Apr 2017 08:25:58 +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 v3O8PtsW020285; Mon, 24 Apr 2017 10:25:55 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id v3O8PrkK020283; Mon, 24 Apr 2017 10:25:53 +0200 Date: Mon, 24 Apr 2017 08:38:00 -0000 From: Jakub Jelinek To: Allan Sandfeld Jensen Cc: gcc-patches@gcc.gnu.org, Uros Bizjak Subject: Re: [PATCH] [x86] Avoid builtins for SSE/AVX2 immidiate logical shifts Message-ID: <20170424082553.GJ1809@tucnak> Reply-To: Jakub Jelinek References: <201704221338.46300.linux@carewolf.com> <201704240951.29932.linux@carewolf.com> <20170424075627.GI1809@tucnak> <201704241002.40719.linux@carewolf.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201704241002.40719.linux@carewolf.com> User-Agent: Mutt/1.7.1 (2016-10-04) X-IsSubscribed: yes X-SW-Source: 2017-04/txt/msg01006.txt.bz2 On Mon, Apr 24, 2017 at 10:02:40AM +0200, Allan Sandfeld Jensen wrote: > > 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 No. Have you really tried that? > the intrinsics to be used incorrectly with non-literal arguments because we > lack the C-extension for constexp to prevent that. Consider e.g. -O2 -mavx2 -mtune=intel: #include __m256i foo (__m256i x, int s) { return (__m256i)__builtin_ia32_psllwi256 ((__v16hi)x, s); } __m256i bar (__m256i x, int s) { return ((s & 0xff) < 16) ? (__m256i)((__v16hi)x << (s & 0xff)) : _mm256_setzero_si256 (); } The first one generates movl %edi, %edi vmovq %rdi, %xmm1 vpsllw %xmm1, %ymm0, %ymm0 ret (because that is actually what the instruction does), the second one movzbl %dil, %edi cmpl $15, %edi jg .L5 vmovq %rdi, %xmm1 vpsllw %xmm1, %ymm0, %ymm0 ret .p2align 4,,7 .p2align 3 .L5: vpxor %xmm0, %xmm0, %xmm0 ret Jakub