From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 80263 invoked by alias); 10 Apr 2018 10:14:13 -0000 Mailing-List: contact fortran-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: fortran-owner@gcc.gnu.org Received: (qmail 80239 invoked by uid 89); 10 Apr 2018 10:14:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,HTML_MESSAGE,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*i:sk:6a8d496, H*f:sk:6a8d496, H*c:alternative X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-yb0-f178.google.com Received: from mail-yb0-f178.google.com (HELO mail-yb0-f178.google.com) (209.85.213.178) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 10 Apr 2018 10:14:11 +0000 Received: by mail-yb0-f178.google.com with SMTP id e5-v6so4078250ybq.13; Tue, 10 Apr 2018 03:14:11 -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=0NUUEv1giwHHvz5TesQzivdl0VYdTx8pY0KmXtkXtwE=; b=oq8HRNiWg1d4WnZ0c3C+8Dsom9s0CFR8wGSRoACwm/nR4/ZNVsHFWuf5zG+5r9uu8B +z0MkP0muZZ1HfChg+Tcj2vnlZUda/2X4GzGY7nz6ZutWb88fFcO3SeK48eDEZ0MDe3O Yt4sEDkQ1HE6TQ5vG7/azhTSw1AGPaSroBpx5x0+IIVHTMp6l1MBxVVDPWMxm6lqxT3n 9oGatir3sYEv0+ViH9Xdw2r8DUQcXhOR+wVg7pFmU7qcZxEp5gMacwOJm+kjMI/sLD0X ZZaUyt04wykGTzXcYU3FhEMIa0O5ro/ekMJklwRzJ7WUjMYvr9RMnk4AVos2j0NJ5VsB MiGg== X-Gm-Message-State: ALQs6tA3rwYVF0Q67xZljsPjemLlS1WTaAGfYBQb5nzUVzbjcWiJ9Sg+ dVEAGl2YxKuajAmDPvqMjw948XZ8PF8zCclyFv8= X-Google-Smtp-Source: AIpwx48gFi6KyiXF3SxmNwHJqwU8ZBIcaKabyN0/wwSOR5X7nxlG3C0GAJsCXPfW90dIi56j9m/aJBMGpjVreNY+kyE= X-Received: by 2002:a25:2ad6:: with SMTP id q205-v6mr14472469ybq.260.1523355249561; Tue, 10 Apr 2018 03:14:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.39.76 with HTTP; Tue, 10 Apr 2018 03:14:08 -0700 (PDT) In-Reply-To: <6a8d496b-d830-5eb2-eba3-c2e452d06493@arm.com> References: <6a8d496b-d830-5eb2-eba3-c2e452d06493@arm.com> From: Janne Blomqvist Date: Tue, 10 Apr 2018 10:14:00 -0000 Message-ID: Subject: Re: libmvec in gcc to have vector math in fortran To: Szabolcs Nagy Cc: GCC Development , Fortran List , Steve Ellcey , nd Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-04/txt/msg00041.txt.bz2 On Tue, Apr 10, 2018 at 12:45 PM, Szabolcs Nagy wrote: > i had a query earlier about libmvec vector functions in fortran: > https://gcc.gnu.org/ml/gcc/2017-11/msg00007.html > > but there were no simple solutions to make math functions vectorizable > in fortran, because it's hard to make libc headers with simd attributes > visible to the fortran front end. > > i think a possible workaround is to have a dummy libmvec implementation > in libgcc.a (or more likely as a separate libgccmvec.a) that just calls > scalar functions from libm like > > vdouble _ZGVbN2v_sin(vdouble x) > { > return (vdouble){sin(x[0]), sin(x[1])}; > } > > and similarly for all relevant single and double precision functions > for all vector lengths and other supported variants. > > then gcc knows that there is an implementation for these functions > available and with the right link order a better implementation from > libmvec can override these dummy implementations. (the cost model > cannot assume a faster vector algorithm than the scalar one though) > > - this allows vectorizing loops with math functions even in fortran, > - and on targets without a libmvec implementation (but with a vector abi), > - and allows users to provide their own vector math implementation > more easily without hacking around glibc math.h (which may not support > vector math or only enable it for a small subset of math functions). > > gcc needs a new cflag and ldflag to enable this. > (maybe -mveclibabi= already present in x86 and ppc can be used for this) > > 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. -- Janne Blomqvist