From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id DD0033858D20 for ; Fri, 5 May 2023 09:14:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DD0033858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1683278060; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=NM6siXuyCWAe1ZMBe435nb+CWdKh1baKukI8XRc7WlQ=; b=DFqvtgfbHh+fUnh8bPhtFmZmzeSo4POpZucSaLElzl4DqnSPfyxAOtUqL/2/pNmkU1ADjO btT7AgujVCWvhdp6ZWc6LLZU9xYAyTp1Z1M/Sl6icPdcSu/SotJYWqsAjv6NTaRKR5HU27 VocHEz9tEfCG4Z7q5Z00sTJKopWah1c= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-70-mIUaSM-lOumYrOOxlDjNig-1; Fri, 05 May 2023 05:14:19 -0400 X-MC-Unique: mIUaSM-lOumYrOOxlDjNig-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id B86E3100F661 for ; Fri, 5 May 2023 09:14:18 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.194.156]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 64FED2166B31; Fri, 5 May 2023 09:14:18 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 3459EFWr1360861 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 5 May 2023 11:14:16 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 3459E53m1360858; Fri, 5 May 2023 11:14:05 +0200 Date: Fri, 5 May 2023 11:13:59 +0200 From: Jakub Jelinek To: Aldy Hernandez Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] gimple-range-op: Improve handling of sqrt ranges Message-ID: Reply-To: Jakub Jelinek References: MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Fri, May 05, 2023 at 11:06:31AM +0200, Aldy Hernandez wrote: > > +/* Compute FUNC (ARG) where FUNC is a mpfr function. If RES_LOW is non-NULL, > > + set it to low bound of possible range if the function is expected to have > > + ULPS precision and similarly if RES_HIGH is non-NULL, set it to high bound. > > + If the function returns false, the results weren't set. */ > > + > > +static bool > > +frange_mpfr_arg1 (REAL_VALUE_TYPE *res_low, REAL_VALUE_TYPE *res_high, > > + int (*func) (mpfr_ptr, mpfr_srcptr, mpfr_rnd_t), > > + const REAL_VALUE_TYPE &arg, tree type, unsigned ulps) > > +{ > > Since you're returning a range of sorts [low, high], would it be cleaner to > return an frange, or is always calculating low/high too expensive? I notice > you avoid it when passing NULL. The point was that the caller can tell which bound it needs, low, high or both and we don't waste time calculating ones we don't need (especially with larger values of ulps). E.g. for the sqrt case we only need one of them, but when I thought about the sin/cos case, I'll probably need both and calling the function twice would mean repeating the even more expensive mpfr call. > Would you mind adding a typedef for the (*func) callback above? I always > find C callbacks a pain to read. I can, what I used comes from elsewhere (builtins.cc/fold-const-call.cc which use it like that). Jakub