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 1CB8B388451F for ; Fri, 18 Mar 2022 18:34:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1CB8B388451F Received: from mail-yb1-f199.google.com (mail-yb1-f199.google.com [209.85.219.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-652-I7WALoc4PeCRz9RuE1oyCg-1; Fri, 18 Mar 2022 14:34:00 -0400 X-MC-Unique: I7WALoc4PeCRz9RuE1oyCg-1 Received: by mail-yb1-f199.google.com with SMTP id b11-20020a5b008b000000b00624ea481d55so7491673ybp.19 for ; Fri, 18 Mar 2022 11:34:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=e07pCRqciurTPESNI2amRcmBnXvpL0tiyzNJGrRF5PI=; b=p2kraxse2k02A+FpbV0SLIaZ3XCY2lJjtYceg/+swvb1rNP9tVbPznc2lNESxXKDpd HylcZv4nfu+loFCFNnN5QxqY7XhdR3uEDkdGR1BuzufVKPrR2gCFyHdqb5lJx04f1VFP 1SceYJ4TXUxB1d5TOX3DvKakcNoXYd0gyDTb7NV0qNiDmSASsQ5sqZS6Dgo4J0VVxPyS cQmXe1FZ/zsRdwET1g9w2uDtcz9dPQ6KK7WIMAHPf9NKvGi/G26lqoz41T6UxkDl1UaM WInGd7HggB4zZBJmV93TgtgYsCMx2qKoe4EqIOv588XjAzeQrhfNf5kUKNMDqx/ePYEu cFZQ== X-Gm-Message-State: AOAM532pCABlNfOY010OhdGKcDhR3wYFzg5Nf8MfaQDoitHEHemvPs7g TUB/UFcXfNVgapwexWO2JMtEQwubN2y/cuY84KFYjnkBzu+BYYX0ZZC/lrWxq5vhILUlVTNRZ0z jlOqeuMipS9Rf5ENfGmykQN6xrwQLn6AiRw== X-Received: by 2002:a0d:d757:0:b0:2e5:beac:5b48 with SMTP id z84-20020a0dd757000000b002e5beac5b48mr10102375ywd.478.1647628439913; Fri, 18 Mar 2022 11:33:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyjdI5kpsyZrDO+anHC+w8CVlXLsOykzJwq0OJbLbrosJxQROK18JN0GSm4QTbZlnTuC+oXL6rKDTfpK4MNQbE= X-Received: by 2002:a0d:d757:0:b0:2e5:beac:5b48 with SMTP id z84-20020a0dd757000000b002e5beac5b48mr10102354ywd.478.1647628439678; Fri, 18 Mar 2022 11:33:59 -0700 (PDT) MIME-Version: 1.0 References: <001c01d837d9$4c8bf060$e5a3d120$@nextmovesoftware.com> <009701d83843$26293a30$727bae90$@nextmovesoftware.com> In-Reply-To: From: Aldy Hernandez Date: Fri, 18 Mar 2022 19:33:48 +0100 Message-ID: Subject: Re: [PATCH] Ignore (possible) signed zeros in operands of FP comparisons. To: Jeff Law Cc: Andrew MacLeod , Roger Sayle , Richard Biener , GCC Patches X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2022 18:34:06 -0000 On Fri, Mar 18, 2022 at 5:01 PM Jeff Law wrote: > > > > On 3/18/2022 7:16 AM, Andrew MacLeod wrote: > > On 3/17/22 19:27, Jeff Law via Gcc-patches wrote: > >> > >> On 3/15/2022 2:03 AM, Roger Sayle wrote: > >>>> -----Original Message----- > >>>> From: Richard Biener > >>>> Sent: 15 March 2022 07:29 > >>>> To: Roger Sayle > >>>> Cc: GCC Patches > >>>> Subject: Re: [PATCH] Ignore (possible) signed zeros in operands of FP > >>>> comparisons. > >>>> > >>>> On Mon, Mar 14, 2022 at 8:26 PM Roger Sayle > >>>> wrote: > >>>>> > >>>>> I've been wondering about the possible > >>>>> performance/missed-optimization > >>>>> impact of my patch for PR middle-end/98420 and similar IEEE > >>>>> correctness fixes that disable constant folding optimizations when > >>>>> worrying > >>>> about -0.0. > >>>>> In the common situation where the floating point result is used by a > >>>>> FP comparison, there's no distinction between +0.0 and -0.0, so some > >>>>> HONOR_SIGNED_ZEROS optimizations that we'd usually disable, are safe. > >>>>> > >>>>> Consider the following interesting example: > >>>>> > >>>>> int foo(int x, double y) { > >>>>> return (x * 0.0) < y; > >>>>> } > >>>>> > >>>>> Although we know that x (when converted to double) can't be NaN or > >>>>> Inf, we still worry that for negative values of x that (x * 0.0) may > >>>>> be -0.0 and so perform the multiplication at run-time. But in this > >>>>> case, the result of the comparison (-0.0 < y) will be exactly the > >>>>> same > >>>>> as (+0.0 < y) for any y, hence the above may be safely constant > >>>>> folded to "0.0 < > >>>> y" > >>>>> avoiding the multiplication at run-time. > > > > I'm going to hazard a guess that this can be handled in the upcoming > > floating point range support? there was a start of a conversation in > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24021 about a month ago. > > > > I know *zero* about floating point, but It seems like when we track > > floating point ranges, we will naturally be able to integrate > > > > _2 = _1 * 0.0; > > _3 = _2 < y_5(D); > > > > that _2 evaluates to +/- 0.0 and when we do look at (_2 < y_5) > > that VRP can simplify that to 0.0 < y? (or any patch which uses > > simplification and ranges). It seems like it should be > > straightforward anyway. Yes, definitely. Ranger is really a propagation engine. The plan all along was to make it type agnostic with a generic vrange class that provides core functionality that each implementation overrides (union, intersect, varying, undefined, etc). Right now we have plans for float ranges, pointer tracking, and eventually string tracking. The generic vrange abstraction is done and queued up for the next release. I have a core float implementation that handles relationals and end points, but the plan is to add bits to track nonzero, infs, nans, etc. Since ranger will just be a propagation engine, range-ops, union, intersection, etc, could propagate not NaN and non Inf for the cast operator above, plus +-0.0 for _2. The float range-op entries would be able to do all sorts of magic by querying the range for _2. Also the simplify_using_ranges class vrp uses could simplify the _2 < y_5 with appropriate smarts. It really does seem pretty straightforward once the vrange and frange classes are in place. All this should be doable for the next stage1, but we could use help with the nuances of frange when the time comes. > Yea, I guess we'd pick it up that way and that's probably cleaner than > what I was originally thinking in this space. > > We realize that 2 is +-0.0. Then we realize that for the comparison, we > can constant propagate +0.0 for _2 since +0.0 and -0.0 behave the same > way. Ideally that removes the last reference to _2 and we DCE away the > multiplication. Yup yup. Aldy > > > jeff >