From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) by sourceware.org (Postfix) with ESMTPS id EC42B3858427 for ; Fri, 26 Aug 2022 16:33:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EC42B3858427 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pf1-x434.google.com with SMTP id y141so2029637pfb.7 for ; Fri, 26 Aug 2022 09:33:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc; bh=j2fUOcfw7hq8NubbMd6UR0inHturq/mLo3t2Ilu9UU4=; b=ihoq3dlrRsm/MfcHtxERL4805ZM6Iawx1R+gWFEZUhWrkf6pt0Q1G830ZyBj5e6IyE Si4oEWmqPOIIDH1iC69cBo/koCuOvOHRNR/d9ZJVvjXkLrH4OLwkOO3Bxz6RvtD5rWOi 4sUfW/4jIXSDa6m4uYyOyKEYgAj/CfSQD9dPFf5nLSCJpmB4Ay9YVuvrfrnsvgAEkroQ nXbOvOA33rnNEVDfgXCwWt7JX6U1G3Nk8uAU072iRp0CGrwz/xL76w6/6zflQ+b4cCil v/WVerCnlvayFH+f4iu1Ht3w0EZCpX/z2hqNERsUbIhZKb3WvNBdqZtxG9lBGR5XA8N+ JkFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc; bh=j2fUOcfw7hq8NubbMd6UR0inHturq/mLo3t2Ilu9UU4=; b=7/JgSDfAkbHn1s8s1l5cH9pmNCBucGF4udLvUsG1lmY6uFbUOavaf8tvk17OSQa37l 2c1VGuXtkMOAOnCUpwc9knAuy7UOOPXzx9XwD6z16SMgb4Cr3703Agz7lkwqk4WRk5sv bnAUGZX2wK/VSJf1s/opgtIUH9nFDOegpPddyW3yDNFQVJVUR70sR9JBLyACHdNhR34v o0QqPHoD0ekDGC3mfpuA+JhJlIPQjcS8p9sNUqTc/IBt8qSROuaWYgcM19cIBJXyztUN tfJ6KNJSlDs/5acoxYxOAKgZ9BNL/FSqHXloyBxZ10nDuYezdAKzyet7iBc4Cpcq4dB/ bdsQ== X-Gm-Message-State: ACgBeo3fqJChiIsrY0eR1u5srvl5aubp7KvU61XwPTdh+0BUFqsQN9YH HgtaPxhpeggd5VqlWOP5Rts= X-Google-Smtp-Source: AA6agR7OiJmR/Uos279L4jPAdUFkCBUD4xR+ccZqqQVqiGY0fI56steXQJeemoih3vJEGZQOqItEcA== X-Received: by 2002:a05:6a00:1c69:b0:536:ccaf:c551 with SMTP id s41-20020a056a001c6900b00536ccafc551mr4555401pfw.59.1661531636814; Fri, 26 Aug 2022 09:33:56 -0700 (PDT) Received: from [172.31.0.204] (c-73-98-188-51.hsd1.ut.comcast.net. [73.98.188.51]) by smtp.gmail.com with ESMTPSA id o186-20020a62cdc3000000b00536fc93b8c8sm1984175pfg.20.2022.08.26.09.33.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 26 Aug 2022 09:33:56 -0700 (PDT) Message-ID: <3ad62c30-5daa-bf7d-43e4-a2027d54d367@gmail.com> Date: Fri, 26 Aug 2022 10:33:54 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Subject: Re: [PATCH] Add set/get functions for negative infinity in real.* Content-Language: en-US To: Aldy Hernandez Cc: gcc-patches References: <20220823103321.879429-1-aldyh@redhat.com> <845babb7-4bb2-35d7-224f-13937b5a0aab@gmail.com> From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,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 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. > or > >> Consider making the "sign" argument a boolean. It's defined as a single >> bit bitfield in the real_value structure. We don't want folks to pass >> in values outside [0..1] for the sign if we can easily avoid it:-) > I was trying to follow all the other functions in real.cc which have > "int sign", though I suppose none of them are exported in the header > file. They probably pre-date using bool types in GCC.  Feel free to update them if you need a mindless task at some point. > > OK pending tests? Of course.  I should have noted that with such a change it'd pre-approved. jeff