From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch [185.70.40.130]) by sourceware.org (Postfix) with ESMTPS id 6753B3850433 for ; Tue, 18 Aug 2020 19:14:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 6753B3850433 Date: Tue, 18 Aug 2020 19:14:19 +0000 To: Segher Boessenkool From: GT Cc: "gcc-patches@gcc.gnu.org" , "dje.gcc@gmail.com" , "jakub@redhat.com" , "wschmidt@linux.ibm.com" , "tuliom@linux.ibm.com" Reply-To: GT Subject: Re: [RFC PATCH v1 1/1] PPC64: Implement POWER Architecture Vector Function ABI. Message-ID: <6U0hNAH-Hsbyqz3rSo-yD6BiTkmnYDdXXWb8S_6TkfzzkrjaQYP-kj7HZYznnu_JwaR4Kp8FqLSf7PIuOSM9r6LVYJZH-1BlHS9eewBVuwk=@protonmail.com> In-Reply-To: <20200817212835.GE28786@gate.crashing.org> References: <1596832552-111518-1-git-send-email-tnggil@protonmail.com> <20200813224928.GJ6753@gate.crashing.org> <20200817212835.GE28786@gate.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 19:14:33 -0000 =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Monday, August 17, 2020 5:28 PM, Segher Boessenkool wrote: > On Mon, Aug 17, 2020 at 05:44:46PM +0000, GT wrote: > > > > This is about the Power binding to some OpenMP API, right? It has > > > nothing to do with "vector" or "ABI" -- we have vectors already, and > > > we have ABIs already, more than enough of each. > > > It is very very VERY hard to review this without being told the prope= r > > > setting here. > > > > What this is about: > > David Edelsohn wanted to have new library functions, one for each of th= ese 6 single-precision functions: > > sinf, cosf, sincosf, expf, logf, powf; and these 6 double-precision fun= ctions: > > sin, cos, sincos, exp, log, and pow. > > For the single-precision functions, the corresponding new functions wou= ld compute 4 results > > simulatneously. For the double-precision functions, the new ones would = compute 2 results > > simultaneously. > > x86_64 has already done something very similar so I thought I would ada= pt as much of their > > documentation and implementation as I could for PPC64. > > Let's start with that. Comments so far? > > That sounds like libmvec? > > I still don't know what this is. > Yes, it is libmvec. Now look at what GCC does to the code in Examples 1 and 2 at this link: https://sourceware.org/glibc/wiki/libmvec x86_64 added functionality to GCC so such code uses the new functions witho= ut the user having to re-write the loops and explicitly call the new functions. We are aiming to provide that same capability for PPC64 in GCC. Bert.