From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 70903 invoked by alias); 14 Jun 2018 10:29:12 -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 70884 invoked by uid 89); 14 Jun 2018 10:29:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-6.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_1,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=questionable, ji, easiest, HX-Received:sk:k7-v6mr X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-lf0-f44.google.com Received: from mail-lf0-f44.google.com (HELO mail-lf0-f44.google.com) (209.85.215.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 14 Jun 2018 10:29:09 +0000 Received: by mail-lf0-f44.google.com with SMTP id d24-v6so8594625lfa.8; Thu, 14 Jun 2018 03:29:08 -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:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+8AhxJQ4bPWSCGdfru9GQN7Fxj63ZgIeJzgxnTM+Qkg=; b=okznygOge9r4cw2agE5bNMpcvMXc++bpJmm+APINsEuro3eO4PlUGbn4vhzzl24Mhv C1KkgY6Z11GLauBu/o1b10gzfkhrlJWqmcIa7iAlIzxbeot2PT2E4aKcSJfnNnqOTxNc jij+CJO/M67LimlvGV+/6/4BQKbB/HL7rv1ZcEIYuffaOVGYssk0/V1xML4V5+uCjqoB uSHmBInkzEysPy4qnFYpiqcpNFtmr7roAAgzTRd3DHMMDkOHsGd6+e+kWLPaCA5LfyUf bhyjsMEER1ONTyn/LaRnaF0FOzJdS+4a78/wrdPeQxtqsalWNVQWkHtTWGmKxShN2H6P G2wg== X-Gm-Message-State: APt69E10svzY3mvZu4smu7eclTjc3YwH/+J5PTG3FGm5ye+w+6pA6BJD iEDeL0p8bq9N13T0Qn1LzjorJqglI6VYn/R6xQw= X-Google-Smtp-Source: ADUXVKLqUCeLVOjRAm2ZYBSd17ieD1eJppd0MMyGJpO1aR5B/5OwnDCrJti9s6iA1mT5CxtsFCZkfSX1O1LxVWl5Ygs= X-Received: by 2002:a2e:5687:: with SMTP id k7-v6mr1428914lje.140.1528972147105; Thu, 14 Jun 2018 03:29:07 -0700 (PDT) MIME-Version: 1.0 References: <6a8d496b-d830-5eb2-eba3-c2e452d06493@arm.com> <80c395e1-9de5-1d9c-35b6-1ccfdfa6a9e5@arm.com> <20180410102954.GB8577@tucnak> <20180410130655.GD8577@tucnak> In-Reply-To: <20180410130655.GD8577@tucnak> From: Richard Biener Date: Thu, 14 Jun 2018 22:41:00 -0000 Message-ID: Subject: Re: libmvec in gcc to have vector math in fortran To: Jakub Jelinek Cc: szabolcs.nagy@arm.com, Janne Blomqvist , nd@arm.com, GCC Development , "fortran@gcc.gnu.org" , sellcey@cavium.com Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-06/txt/msg00168.txt.bz2 On Tue, Apr 10, 2018 at 3:07 PM Jakub Jelinek wrote: > > On Tue, Apr 10, 2018 at 02:55:43PM +0200, Richard Biener wrote: > > > 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). > > 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. As-is the above doesn't work - it doesn't seem to redeclare sin() in a way that it is 'const', thus dependence analysis rejects calls to it. I'm playing with the following subroutine bar (a) use, intrinsic :: iso_c_binding, only: c_double interface pure function sin(x) bind(C,name="sin") result(res) !$omp declare simd notinbranch import real(c_double) :: res real(c_double),value :: x end function sin end interface real(8) a(100,100) do I=1,100 do J = 1,100 a(j,i) = sin(a(j,i)) end do end do end subroutine bar 'pure' makes it pure but there doesn't seem to be a way to make it const? Any hint on how to improve the interface above? With -fopemp -fopenmp-simd -Ofast the loop should be vectorized (if I got index order correct). That is, fortran doesn't seem to do anything like "merging" the above declaration with the existing builtin so the binding above needs to be complete. I'm still thinking of exposing libmvec using a include/module that gets implicitely picked up by gfortran if present. Richard. > I see Fortran now supports already > !GCC$ attributes stdcall, fastcall::test > Could we support > !GCC$ attributes simd > and > !GCC$ attributes simd('notinbranch') > too? > > Jakub