From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 97644 invoked by alias); 10 Apr 2018 12:55:48 -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 96847 invoked by uid 89); 10 Apr 2018 12:55:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-lf0-f50.google.com Received: from mail-lf0-f50.google.com (HELO mail-lf0-f50.google.com) (209.85.215.50) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 10 Apr 2018 12:55:46 +0000 Received: by mail-lf0-f50.google.com with SMTP id q9-v6so11507260lfk.9; Tue, 10 Apr 2018 05:55:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6zVeEfNYbg5cePGjIukOZ0ZQZISLmV4JN0vgfa/JWpg=; b=bV8lc699nJJrPAr6IIUZNhb29RcoWmUhzsY6chuuo8xC2C2p2Yg5qC3itFxk2u/ykf A6sf8IXGkngUPdAJXUEsW0LHm++eWeIdvstlK6MEg1hkJkxoKeDSRJvi4gufjLOATUCt K00kk8/CGYGPMBdjmHeOTTt8EAdeXS0wlMm1NiICtWBjZBGzMHxG+sBnn+lmgvNTVtI1 IJrTMhQU/yRrqAusSZmU+2MyGYtZVVQi3UY7V435EuapwXDNfFKQ2/Wo/k6h51SlouSQ Cw50HLI4Vbyz9jFd98hE6Un98yeo7LjTCSNpB+7BKKvXj7TuQ3IFZG2HY6l1HGGeNApf d7og== X-Gm-Message-State: ALQs6tA0MhN1cpCW+K17jtCvZNXWce1SiL++OpFEg1J1Y89uNlwLZzaV yDzehXTwgtb8NFEHSnRCPuDJ0907D7bsZgvj+H8= X-Google-Smtp-Source: AIpwx4+EgGnwVYnkKZOWT+tzNC1A7gU7CLkJMgaiEqQBB4V0bLvRUqJwVnk0jPs/ni4fvPxf3vI7DlZNUie8JRhPUyw= X-Received: by 10.46.150.135 with SMTP id q7mr179926lji.67.1523364944346; Tue, 10 Apr 2018 05:55:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.66.218 with HTTP; Tue, 10 Apr 2018 05:55:43 -0700 (PDT) In-Reply-To: <20180410102954.GB8577@tucnak> References: <6a8d496b-d830-5eb2-eba3-c2e452d06493@arm.com> <80c395e1-9de5-1d9c-35b6-1ccfdfa6a9e5@arm.com> <20180410102954.GB8577@tucnak> From: Richard Biener Date: Tue, 10 Apr 2018 13:26:00 -0000 Message-ID: Subject: Re: libmvec in gcc to have vector math in fortran To: Jakub Jelinek Cc: Szabolcs Nagy , Janne Blomqvist , nd@arm.com, GCC Development , Fortran List , Steve Ellcey Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-04/txt/msg00067.txt.bz2 On Tue, Apr 10, 2018 at 12:29 PM, Jakub Jelinek wrote: > On Tue, Apr 10, 2018 at 11:22:03AM +0100, Szabolcs Nagy wrote: >> On 10/04/18 11:14, Janne Blomqvist wrote: >> > As I mentioned previously in that thread you linked to, the fortran >> > frontend never generates a direct call to libm sin(), or for that matter >> > ZGVbN2v_sin(). Instead it generates a "call" to __builtin_sin(). And >> > similarly for other libm functions that have gcc builtins. The >> > middle-end optimizers are then free to do whatever optimizations they >> > like on that __builtin_sin call, such as constant folding, and at least >> > as far as the fortran frontend is concerned, vectorizing if -mveclibabi= >> > or such is in effect. >> >> the generated builtin call is not the issue (same happens in c), >> the knowledge about libc declarations is. >> >> the middle-end has no idea what functions can be vectorized, >> only the libc knows it and declares this in c headers. >> >> this is the problem i'm trying to solve. > > And the easiest solution is in the Fortran FE based on some flag > (e.g. -mveclibabi=glibc) through a target hook add > __attribute__((__simd__ ("notinbranch"))) > to the builtins like __builtin_sin etc. that have them in the > glibc header (x86_64 -m64 and -ffast-math only): > > # undef __DECL_SIMD_cos > # define __DECL_SIMD_cos __DECL_SIMD_x86_64 > # undef __DECL_SIMD_cosf > # define __DECL_SIMD_cosf __DECL_SIMD_x86_64 > # undef __DECL_SIMD_sin > # define __DECL_SIMD_sin __DECL_SIMD_x86_64 > # undef __DECL_SIMD_sinf > # define __DECL_SIMD_sinf __DECL_SIMD_x86_64 > # undef __DECL_SIMD_sincos > # define __DECL_SIMD_sincos __DECL_SIMD_x86_64 > # undef __DECL_SIMD_sincosf > # define __DECL_SIMD_sincosf __DECL_SIMD_x86_64 > # undef __DECL_SIMD_log > # define __DECL_SIMD_log __DECL_SIMD_x86_64 > # undef __DECL_SIMD_logf > # define __DECL_SIMD_logf __DECL_SIMD_x86_64 > # undef __DECL_SIMD_exp > # define __DECL_SIMD_exp __DECL_SIMD_x86_64 > # undef __DECL_SIMD_expf > # define __DECL_SIMD_expf __DECL_SIMD_x86_64 > # undef __DECL_SIMD_pow > # define __DECL_SIMD_pow __DECL_SIMD_x86_64 > # undef __DECL_SIMD_powf > # define __DECL_SIMD_powf __DECL_SIMD_x86_64 > > The sincos/sincosf stuff is questionable, because some glibc versions > implement it incorrectly and the simd ("notinbranch") attribute isn't that > useful for it anyway, we'd want to use extra clauses so that it doesn't need > to do scatter stores. I wonder if it is possible for glibc to ship a "module" for fortran instead containing the appropriate declarations and gfortran auto-include that (if present). Hard-coding stuff like suggested above is of course possible but not very forward compatible with changes in glibc. Richard. > Jakub