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.129.124]) by sourceware.org (Postfix) with ESMTPS id 40BDE38515E9 for ; Fri, 26 Aug 2022 16:38:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 40BDE38515E9 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=1661531907; h=from:from: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=8tKIIVMXoQo7cL5C+gFz+0vWBHqod6hT9bye66AOILc=; b=JHrAaPG8KBjcbAtTkCHPguDK6kVnVcu3CyvgfKi4VJUTcNZ8l8zvS/WbZQv1Ykdcglio4H 7UFfo+z/NO9h1kaWjiJ03Awi5n3oidBLElEfKzVJm+6/Y4C8GuXfa8zUe30PIvTFbwcgFG N5nDlJlrx0/KQvhAqG6+eRxl5ffdpj8= Received: from mail-oa1-f69.google.com (mail-oa1-f69.google.com [209.85.160.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-621-bSTkOo-vOL2D6pxdBBkj3g-1; Fri, 26 Aug 2022 12:38:26 -0400 X-MC-Unique: bSTkOo-vOL2D6pxdBBkj3g-1 Received: by mail-oa1-f69.google.com with SMTP id 586e51a60fabf-11c90b642d4so552887fac.13 for ; Fri, 26 Aug 2022 09:38:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=8tKIIVMXoQo7cL5C+gFz+0vWBHqod6hT9bye66AOILc=; b=lxjeajjbDHrGUtWrYgDw/2f65uNzePq7EpCFQWLejqCWCMGKDhwaE1lRFBsHDxJ7Dc VM95NlSY7m5m/+ErbKB1rSXqz0bZz1/MX/sE/wor2hfcJx/MPZ9TGv5mxRi5sJxQeutL RtRG9ui6xU8v4w/37e2VQUIVPMpdJR3PJt16DSYtT3d159jE73Qg0C3TgkN2hQjOwNSy bkha0I3kD7u0kaCtSckBwaqylLFPdo6H3fyPgQon4H94KbgIi0iF+UWNhfbmwN75Nrc/ bulsBvHLBKf8dzaEMfnleM9UpBxZvsdJlZe5BisqU5rCipU2uz9xb5LA6gPvleNuWJHQ CAUg== X-Gm-Message-State: ACgBeo1CLdg3jdsyTZg98gThfTQ8Bf2h+HlQOKJtSvMqk1NPWwN2g7bk tfLHr5OZJQfdXHpzTBrQ1LMXlsHOvS9HRhumF0q2d6U3G7VqtQ1q6Y4n0rESl2nOHrxT8B0WVKq +xHEHcz7K331xa8qzJmJlLfPCEbA54Ysrmg== X-Received: by 2002:a05:6870:210b:b0:10b:ed11:4e2d with SMTP id f11-20020a056870210b00b0010bed114e2dmr2241519oae.265.1661531905805; Fri, 26 Aug 2022 09:38:25 -0700 (PDT) X-Google-Smtp-Source: AA6agR6iC5eWHqusC9xOrbp/8HkGNOxpnXcLijWYyi2bg0d1XpQEo0qlitBmhDpakepnbpKvTudGr/kXw3+BPE+6lSY= X-Received: by 2002:a05:6870:210b:b0:10b:ed11:4e2d with SMTP id f11-20020a056870210b00b0010bed114e2dmr2241509oae.265.1661531905555; Fri, 26 Aug 2022 09:38:25 -0700 (PDT) MIME-Version: 1.0 References: <20220823103321.879429-1-aldyh@redhat.com> <845babb7-4bb2-35d7-224f-13937b5a0aab@gmail.com> <3ad62c30-5daa-bf7d-43e4-a2027d54d367@gmail.com> In-Reply-To: <3ad62c30-5daa-bf7d-43e4-a2027d54d367@gmail.com> From: Aldy Hernandez Date: Fri, 26 Aug 2022 18:38:14 +0200 Message-ID: Subject: Re: [PATCH] Add set/get functions for negative infinity in real.* To: Jeff Law Cc: gcc-patches X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,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, Aug 26, 2022 at 6:34 PM Jeff Law wrote: > > > > On 8/26/2022 10:24 AM, Aldy Hernandez wrote: > > On Fri, Aug 26, 2022 at 6:08 PM Jeff Law via Gcc-patches > > wrote: > >> > >> > >> On 8/23/2022 4:33 AM, Aldy Hernandez via Gcc-patches wrote: > >>> For the frange implementation with endpoints I'm about to contribute, > >>> we need to set REAL_VALUE_TYPEs with negative infinity. The support > >>> is already there in real.cc, but it is awkward to get at. One could > >>> call real_inf() and then negate the value, but I've added the ability > >>> to pass the sign argument like many of the existing real.* functions. > >>> > >>> I've declared the functions in such a way to avoid changes to the > >>> existing code base: > >>> > >>> // Unchanged function returning true for either +-INF. > >>> bool real_isinf (const REAL_VALUE_TYPE *r); > >>> // New overload to be able to specify the sign. > >>> bool real_isinf (const REAL_VALUE_TYPE *r, int sign); > >>> // Replacement function for setting INF, defaults to +INF. > >>> void real_inf (REAL_VALUE_TYPE *, int sign = 0); > >>> > >>> Tested on x86-64 Linux. > >>> > >>> OK? > >>> > >>> gcc/ChangeLog: > >>> > >>> * real.cc (real_isinf): New overload. > >>> (real_inf): Add sign argument. > >>> * real.h (real_isinf): New overload. > >>> (real_inf): Add sign argument. > >> Funny in that I've fairly recently had the desire to do something a bit > >> similar. Let's consider 0.5, which we have a dconsthalf, but we don't > >> have dconstmhalf for -0.5. To get that value I create a dconsthalf > >> object and flip its sign. Similarly for a variety of other special > >> constants (particularly powers of two, but a few others as well). > > Ugh, yeah. I've been doing a lot of gymnastics in this space because > > frange's will have REAL_VALUE_TYPE endpoints. > In our case we have instructions that can make of various FP constants, > some of which may be negative. So we need to be able to recognize those > constants. Leading to having to do similar gymnastics as what you're doing. It seems real.* needs some minor TLC. For one, a lot of these functions should be inlined. I suppose it wasn't meant to be abused the way we're about to in range-op-float.cc :-). Thanks. Aldy