From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) by sourceware.org (Postfix) with ESMTPS id 523A2385843E for ; Mon, 29 Aug 2022 14:20:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 523A2385843E 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-pg1-x529.google.com with SMTP id r22so7827586pgm.5 for ; Mon, 29 Aug 2022 07:20:48 -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:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc; bh=DrQ1hyQ/h0bvW8gKcv9IrW9mRmTR/gZrdeuxz5DYEqI=; b=PLAR1Dezx6WXI9CTeTDum6HXIDh3wd1I5FK/UrL8X2lSM6DV2z+Kd5KTUxvAVp9JNh icUuXjruzttSmaLaCS4zQ5Wu4nOnqGRs9K8mUtSrMcGpkX7pUA+BtJalaaXO+K2v39d1 tGFCqZdsT1NNAWpUl8uRC9Yp3A62apqUOWPsBXh6oLPK4GPG3h0az/6CYDanB13ZSqBA cLm7XxT2gKaRqQ82HtpXFw56brEQEZvweSMBAPtx6ix5//7iIUGIS74NCtOLyPcN0pp4 nhMDSDNS70k2jeq74uC9Sr4vdstpfWuleFM5Xo255a9QsKLFTd2LxVOq6Nf4P+2v4u8C kbBw== 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:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc; bh=DrQ1hyQ/h0bvW8gKcv9IrW9mRmTR/gZrdeuxz5DYEqI=; b=uAMouklHZjxFVkEAbqnBMZLLrGnhM1Qqr5y8A5J0cilDd4vvS7LNeJ6VJcgSfiRRGZ zGaIAmHORMODV0chmirnffEPzT2Qogj7Al+Esl+Wmx4jX8pf6fJMwDJJ/GND5t5Oyvxg ijCYpvLD0/eEwfG+FoygFpK0Q7eoAaQ7eHQGUJHaOcpVrz5sAQbmZwyVN0q+8ddTFJCr XSFAwwapVfavUVVvE9gm5mu/N5Y9lnqtphjnaUg7yQ66sMGTqHRYxUAtzhWyPWYLGKhM WpSNuKZYjRCTEC5SdL8LovswipOfRn+nxvE69yuWxG+w782gqOUsv+eN4R/vi+QwhLDS UPTA== X-Gm-Message-State: ACgBeo2zLPZu8+F2Ge8Pzp74YfeQ6j71V8+iCnk1YSlnjdUYJN6EAyIX zqvAI6odBQnlRIPc0uBYEriXli8wAmc= X-Google-Smtp-Source: AA6agR5RCNMxGeEpRpy4HVHUj5c+EbEeY9y1JY7JvEBtizaCaBG7K2UmurarrgO1OUoWRwAGhVb5Tw== X-Received: by 2002:a63:5702:0:b0:42a:b77b:85b3 with SMTP id l2-20020a635702000000b0042ab77b85b3mr13735717pgb.263.1661782845988; Mon, 29 Aug 2022 07:20:45 -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 20-20020a631354000000b0040ced958e8fsm6496637pgt.80.2022.08.29.07.20.44 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 29 Aug 2022 07:20:45 -0700 (PDT) Message-ID: <616b4af5-e3b7-844e-5dcf-a73a5280d114@gmail.com> Date: Mon, 29 Aug 2022 08:20:44 -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] [ranger] x == -0.0 does not mean we can replace x with -0.0 Content-Language: en-US To: gcc-patches@gcc.gnu.org References: <20220826154606.1155977-1-aldyh@redhat.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.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_NUMSUBJECT,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no 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/29/2022 7:31 AM, Aldy Hernandez via Gcc-patches wrote: > On Mon, Aug 29, 2022 at 3:22 PM Jakub Jelinek wrote: >> On Mon, Aug 29, 2022 at 03:13:21PM +0200, Aldy Hernandez wrote: >>> It seems to me we can do this optimization regardless, but then treat >>> positive and negative zero the same throughout the frange class. >>> Particularly, in frange::singleton_p(). We should never return TRUE >>> for any version of 0.0. This will keep VRP from propagating an >>> incorrect 0.0, since all VRP does is propagate when a range is >>> provably a singleton. Also, frange::zero_p() shall return true for >>> any version of 0.0. >> Well, I think for HONOR_SIGNED_ZEROS it would be nice if frange was able to >> differentiate between 0.0 and -0.0. >> One reason is e.g. to be able to optimize copysign/signbit - if we can >> prove that the sign bit on some value will be always cleared or always set, >> we can fold those. >> On the other side, with -fno-signed-zeros it is invalid to use >> copysign/signbit on values that could be zero (well, nothing guarantees >> whether the sign bit is set or clear), so for MODE_HAS_SIGNED_ZEROS && >> !HONOR_SIGNED_ZEROS it is best to treat contains_p as {-0.0,0.0} being >> one thing (just not singleton_p) and not bother with details like whether >> a range ends or starts with -0.0 or 0.0, either of them would work the same. >> And for !MODE_HAS_SIGNED_ZEROS, obviously 0.0 can be singleton_p. > *head explodes* > > Ok, I think I can add a zero property we can track (like we do for > NAN), and set it appropriately at constant creation and upon results > from copysign/signbit. However, I am running out of time before > Cauldron, so I think I'll just treat +-0.0 ambiguously for now, and do > that as a follow-up. We definitely want to be able to track +-0.0 and distinguish between them.  IIRC there's cases where you can start eliminating comparisons and arithmetic once you start tracking -0.0 state. Jeff