From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 55409 invoked by alias); 6 Dec 2019 11:39:15 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 54724 invoked by uid 89); 6 Dec 2019 11:39:14 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=HX-Languages-Length:1650 X-HELO: mail-lj1-f171.google.com Received: from mail-lj1-f171.google.com (HELO mail-lj1-f171.google.com) (209.85.208.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 06 Dec 2019 11:39:13 +0000 Received: by mail-lj1-f171.google.com with SMTP id c19so7266101lji.11 for ; Fri, 06 Dec 2019 03:39:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=7rqpGaiLksNwl4vZSDS63TC+mbPhj4EZHRaxUeA/tGk=; b=SJD2H5dZvLUoOm3NaOUx/xyooBM/sZCbBpgtalx0RIGgTM8uKz9KdYPb/YUd92waJL Nmk8/nFwVFGAWoG67SHho+Vn10FHzfShjvawmpmaFkMczBBaDzXdm6VuRsHuA9cZBwrP 9giAKO8GyVhJfF6ZCQnI0NNFjL/LDh4OgvlGTKza+3AfH0zR9BKvYfLGvMy08hS7ZZM0 MxrtI4MOStJC9qhstdUlL1+TZjN8RPadvARaZE0sKsQXvUDUHCwLjks+NLCLga407FL5 vVoJT6IqS5cottaL1jO/mYyCBbhR77VYTq+UFfBZifNdgctUkWPOoEy+NDzu2mAbaVLg 5+AA== MIME-Version: 1.0 References: <0728c06a-d506-e8e8-c4a5-9187a7047f5f@arm.com> <3F536966-92DE-49A3-A432-5646981EE26F@gmail.com> <20191206111540.GC10088@tucnak> In-Reply-To: <20191206111540.GC10088@tucnak> From: Richard Biener Date: Fri, 06 Dec 2019 11:39:00 -0000 Message-ID: Subject: Re: PPC64 libmvec implementation of sincos To: Jakub Jelinek Cc: GT , "gcc@gcc.gnu.org" , Szabolcs Nagy , nd , Bill Schmidt Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2019-12/txt/msg00104.txt.bz2 On Fri, Dec 6, 2019 at 12:15 PM Jakub Jelinek wrote: > > On Fri, Dec 06, 2019 at 11:48:03AM +0100, Richard Biener wrote: > > So I used > > > > void sincos(double x, double *sin, double *cos); > > _Complex double __attribute__((__simd__("notinbranch"))) > > __builtin_cexpi (double); > > While Intel-ABI-Vector-Function-2015-v0.9.8.pdf talks about complex numbe= rs, > the reason we punt: > unsupported return type =E2=80=98complex double=E2=80=99 for simd > etc. is that we really don't support VECTOR_TYPE with COMPLEX_TYPE element > type, I guess the vectorizer doesn't do anything with that either unless > some earlier optimization was able to scalarize the complex halves. > In theory we could represent the vector counterparts of complex types > as just vectors of double width with element type of COMPLEX_TYPE element > type, have a look at what exactly ICC does to find out if the vector > ordering is real0 complex0 real1 complex1 ... or > real0 real1 real2 ... complex0 complex1 complex2 ... > and tweak everything that needs to cope. I hope real0 complex0, ... Anyway, the first step is to support vectorizing code where parts of it are already vectors: typedef double v2df __attribute__((vector_size(16))); #define N 1024 v2df a[N]; double b[N]; double c[N]; void foo() { for (int i =3D 0; i < N; ++i) { v2df tem =3D a[i]; b[i] =3D tem[0]; c[i] =3D tem[1]; } } that can be "re-vectorized" for AVX for example. If you substitute _Complex double for the vector type we only handle it during vectorization because forwprop combines the load and the __real/imag which helps. Richard. > Jakub >