From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) by sourceware.org (Postfix) with ESMTPS id 913E23858C20 for ; Mon, 29 Aug 2022 15:08:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 913E23858C20 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-pj1-x1031.google.com with SMTP id l5so4404343pjy.5 for ; Mon, 29 Aug 2022 08:08:25 -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=J2Pd7hbb6Jc2OG1asOZ5h9Rwy5qpx6exbsOG1fNq7fA=; b=j1YPsgveI1sJQk3PcAmU5oTOT9zFztBNQGgK8s/KcSkwwaoMi6JudKMpdj5UCzr0TK t9H2CkHBSjqIBvqsnOMKxv/yYkdfj8CpkDmU1CM9kIHZ8gEGk6e57Aom5n149+s5WOB+ RaoWHQ+SZXLJMkdWU5dXj2DOx5UXBpP+7l46xzQgM0vtqs9fVHQhm2nyyPyaawdAGNiO EVxjqHb0HJWHPgLEG0L4p/BxXQXyr6t5RIxOze3dIHgcYXEJ46iHr6z89Em2XFrAn0Y+ hIVZtDtNUgoGu1PEnUgsh+Cs7ur30nVpjoxuvaMlJsBtedh3BKgJpInbEBhn8M+qraFI wAyA== 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=J2Pd7hbb6Jc2OG1asOZ5h9Rwy5qpx6exbsOG1fNq7fA=; b=ZAVTGkNF0dBf7TeUxRuKlaeRmSz2pwNtg1bNMJ5sEEBdb8z8LsGeY2w6rrokoCCW2x oSSf8O2j7cZEeF0mAuCIZK+cSwYyvK1Bj+Uns/4A4RIH4zFOk/SxcHfZVl6jiIMuK9zL Nrbl4RwDabYSEYI0FMAg5qz8jcC1SHU7oOBaVYMsk9DneI9e8E45KZhBYHSC9TS8t5UP XQ3tPTv/aUzGFhPlkX7cb0P5Dn2hKHWRADEQPQ7GziNF49iMB4gfuECio1oyroOEQZlF dSp+m1wPKHkX4a0ClNSTSUr3HXoseAv0ZzKa3BfhPFP70dYzyEbZuKIc1YcvArhER9sk GIPQ== X-Gm-Message-State: ACgBeo0xMu7JWdDH3Nb+3IMBNh0QTkkAb5zyAU2emQMAMqG4bgLozeeg RI520lKM6H3w/iIdgS4Qqo4= X-Google-Smtp-Source: AA6agR5Dime1qIatyZY+MjH+c2H/gxeN/1gTTlOJF7HSVfYhfz+7j5QKmpfJAq8vHEX60z4H8V4Suw== X-Received: by 2002:a17:903:2d0:b0:172:b63b:3a1e with SMTP id s16-20020a17090302d000b00172b63b3a1emr17158239plk.76.1661785703655; Mon, 29 Aug 2022 08:08:23 -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 g15-20020aa796af000000b0052d9d95bb2bsm1272074pfk.180.2022.08.29.08.08.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 29 Aug 2022 08:08:23 -0700 (PDT) Message-ID: Date: Mon, 29 Aug 2022 09:08:21 -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: Aldy Hernandez Cc: gcc-patches References: <20220826154606.1155977-1-aldyh@redhat.com> <616b4af5-e3b7-844e-5dcf-a73a5280d114@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.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 8:26 AM, Aldy Hernandez wrote: > On Mon, Aug 29, 2022 at 4:22 PM Jeff Law via Gcc-patches > wrote: >> >> >> 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. > Absolutely. That was always the plan. However, my goal was just to > add relop stubs so others could flesh out the rest. Alas, I'm way > over that now :). We're tracking NANs, endpoints, infinities, etc. Well, we'll probably cycle back and forth a bit between the solver and figuring out what we need to track. Related: I had a short email thread with Siddhesh and Carlos WRT the idea of putting in some __builtin_unreachables into the math routines.  They're generally OK with it, though we do need to verify those conditionals aren't generating extra code.   So there's a potential path forward for that side of the problem as well. > > However, I'm hoping to forget as many floating point details, as fast > as possible, as soon as I can ;-). Actually FP isn't that bad -- I'd largely avoided it for decades, but didn't have a choice earlier this year.  And there's a lot more headroom for improvements in the FP space than the integer space IMHO. Jeff