From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 90561 invoked by alias); 26 Aug 2019 07:07:28 -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 90523 invoked by uid 89); 26 Aug 2019 07:07:27 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-8.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.1 spammy=fd, HX-Received:aa7 X-HELO: mail-ed1-f53.google.com Received: from mail-ed1-f53.google.com (HELO mail-ed1-f53.google.com) (209.85.208.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 26 Aug 2019 07:07:25 +0000 Received: by mail-ed1-f53.google.com with SMTP id w5so25005676edl.8 for ; Mon, 26 Aug 2019 00:07:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CZyjjtTea9BRcNHuKxO5wNoeNaUwKASnZR7bo2FrcIA=; b=e0sbDPVTuSObq9kzuQViD6bdnSJTqH80gLVTdtuvgDL+UZlr+FdnjAQyl1etnucLOq 4sGckjrnREXAtQAiXzQPxVmAXIeK45V2PJeAiOGFzSBr9Ty7IfcIRzaYKnJS0WfyMezR rIXNeFJSFhXQ0xddV4lJcHB+W2AlW5VNReXzsmn2sqEvZXpbbYxHkkf4qCa51w6MSQMz wS2364Ac7jtel5vw88SCPvdznCusjj49gLY/r9gOU8ZJCkb3Gq6BfmV8JiiBLsFTb6MP J8s4zn4er1Q6DaEHtPLWnbK2oLCbyT+3+iZ+DZiGo87CU+kJzUOqLsxwSX/AcTDKum3w OS1A== MIME-Version: 1.0 References: <20190821182852.GG31406@gate.crashing.org> <20190821191722.GH31406@gate.crashing.org> <20190822062503.GI31406@gate.crashing.org> <20190822095620.GK31406@gate.crashing.org> <20190825164717.GO31406@gate.crashing.org> In-Reply-To: <20190825164717.GO31406@gate.crashing.org> From: Tejas Joshi Date: Mon, 26 Aug 2019 07:07:00 -0000 Message-ID: Subject: Re: Expansion of narrowing math built-ins into power instructions To: gcc@gcc.gnu.org Cc: Martin Jambor , hubicka@ucw.cz, segher@kernel.crashing.org, joseph@codesourcery.com Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg00214.txt.bz2 Hello. Sorry for not being clear. I am confused about some modes here. I meant, just as we expanded fadd (which narrows down from double to float) with add_truncdfsf3, how can I expand faddl (which narrows down long double to float). Wouldn't I require TFmode -> SFmode as add_trunctfsf3 just as Joseph had previously mentioned? And if yes, the operand constraints would still be f,d and d for TF->SF or what? Also, just as we generated fadds/xsaddsp instructions for fadd, would I be generating the same ones for faddl and fadd/xsadddp for daddl (long double to double) or something different? all for ISA 2.07. (for ISA 3.0, I might use IEEE128/FLOAT128 round-to-odd instructions like add_odd followed by conversion to narrower?) Thanks, Tejas On Sun, 25 Aug 2019 at 22:17, Segher Boessenkool wrote: > > [ Please don't top-post ] > > On Sun, Aug 25, 2019 at 07:32:01PM +0530, Tejas Joshi wrote: > > I want to extend this patch for FADDL and DADDL. What operand > > constraints should I use for TFmode alongside "f"? > > It depends on the instruction you use, and what registers that then > works on. GPRs get "r", FPRs get "f" for SFmode but "d" otherwise, the > VRs get "v", if all VSRs are allowed you get "wa". And there are some > mode attributes to go with mode iterators for when you handle multiple > modes (which you always do, you need to handle KF as well). > > What machine insns do you want to generate? There most likely is > something a lot like it already, so take that as example? > > > > In cases where long double and double have the same mode, > > >the daddl function should use the existing adddf3 pattern. > > Sure, that probably should be handled in generic code (not rs6000). > Where it would generate an adddfdf2 it should just do an adddf3. > > > So, should I use adddf3 for DADDL directly? How would I map the > > add3 optab with DADDL? > > Simply check if source and target mode are the same? > > > Segher