From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32635 invoked by alias); 18 Apr 2018 08:41:09 -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 32604 invoked by uid 89); 18 Apr 2018 08:41:07 -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=H*Ad:D*cavium.com, H*f:sk:2d78162, H*i:sk:2d78162 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-lf0-f53.google.com Received: from mail-lf0-f53.google.com (HELO mail-lf0-f53.google.com) (209.85.215.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 18 Apr 2018 08:41:06 +0000 Received: by mail-lf0-f53.google.com with SMTP id v207-v6so1396491lfa.10; Wed, 18 Apr 2018 01:41:05 -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=IpPAP3Ha8tL0ULeUUHLKqJV+wW/axB5w9V04RuIluO8=; b=bPoso/mrHGEkRSfTyX77jSn2CN+HlxuzJP5nhHL+OnSKyoB3KhH41RPvUIZP+Uztyt MFEJrJ2JK+zHLuuOn3vX1FLIhMbHns8k2eWsUqmi48R7LnL3ct3Haaj01oQyTeR3e9Dp /e8EWTwCQw22em5QiMoVrDJujOi8GwKm/90ki1ORwof5/OY1RRyyKgIq2rPP1djHnPXW cAmRcXXptPFJbi4zF4Dbti8p728dGrwoPQH1pZn80/BgtKiSp9FjnBZfOb7JBnKp8G3u MjPgAB+nHsQ9NhLRZMoxIMzyq0VKrgkEF3/YEKWNXxQShzsvcLPOQVgpAdb27KgWr1QQ SKqg== X-Gm-Message-State: ALQs6tB1VOz20uGRRhgnagYk/kqiy0NmxGrWBlkGzoF6m79Lue75ndFU /isk62SnoHg4mDmrD7jOpafnpA3aIpI+ZLlrOtg= X-Google-Smtp-Source: AIpwx49260lQR04+1Dh+OqCh9Um4PN2kR0zvgMo1ePQas9+dTPKAkQpDlTMf86wn16LpM1pYUetvvUT+WkvrbDPAgxc= X-Received: by 10.46.73.73 with SMTP id b9mr305129ljd.118.1524040863846; Wed, 18 Apr 2018 01:41:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.101.151 with HTTP; Wed, 18 Apr 2018 01:41:03 -0700 (PDT) In-Reply-To: <2d781626-82f5-6a32-e515-121f7952ce94@arm.com> References: <6a8d496b-d830-5eb2-eba3-c2e452d06493@arm.com> <80c395e1-9de5-1d9c-35b6-1ccfdfa6a9e5@arm.com> <20180410102954.GB8577@tucnak> <20180410130655.GD8577@tucnak> <1308CDF7-94DB-414B-900C-03B21C015D59@gmail.com> <2d781626-82f5-6a32-e515-121f7952ce94@arm.com> From: Richard Biener Date: Wed, 18 Apr 2018 08:57:00 -0000 Message-ID: Subject: Re: libmvec in gcc to have vector math in fortran To: Szabolcs Nagy Cc: Jakub Jelinek , nd@arm.com, Janne Blomqvist , GCC Development , Fortran List , Steve Ellcey Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-04/txt/msg00102.txt.bz2 On Tue, Apr 17, 2018 at 3:54 PM, Szabolcs Nagy wrote: > On 10/04/18 14:27, Richard Biener wrote: >> >> On April 10, 2018 3:06:55 PM GMT+02:00, Jakub Jelinek >> wrote: >>> >>> On Tue, Apr 10, 2018 at 02:55:43PM +0200, Richard Biener wrote: >>>> >>>> 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). >>> >>> >>> Then we'd run into module binary format changing every release, so hard >>> for >>> glibc to ship that. >>> >>> Another thing is how would we express it in the module, >>> we could just use OpenMP syntax, >>> interface >>> function sin(x) bind(C,name="__builtin_sin") result(res) >>> import >>> !$omp declare simd notinbranch >>> real(c_double) :: res >>> real(c_double),value :: x >>> end function >>> end interface >>> but we'd need to temporarily enable OpenMP while parsing that module. >>> I see Fortran now supports already >>> !GCC$ attributes stdcall, fastcall::test >>> Could we support >>> !GCC$ attributes simd >>> and >>> !GCC$ attributes simd('notinbranch') >>> too? >> >> >> Maybe we can also generate this module in a fixinlclude way? >> > > ideally everything should work magically but i think > it's good to have a big hammer solution that's easy > to reason about. > > the gcc vectorizer should be testable independently > of glibc, and users should be able to specify what > can be vectorized. > > if this is via a per-frontend declaration syntax, > then i see implementation and usability issues, while > those are sorted out a single flag that requests every > function known to gcc to be vectorized sounds to me a > viable big hammer solution: easy to implement and > enables users to start experimenting with simd math. > > (the implementation may use a preincluded fortran > module internally, but i think it makes sense to > have a single flag ui too) OK, so we could add a -fveclibabi=openmp which means implicitely annotating all math (or others we see fit) builtins with openmp-simd. But then the user has to provide a library with implementations. Or we arrange for them to be emitted in each TU, somehow weakly binding, if the target supports that, implementing the desired ABI but using trivial implementations dispatching to the scalar libm routines. Richard.