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 3F0B43858D32 for ; Mon, 29 Aug 2022 15:29:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3F0B43858D32 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=1661786968; 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=N/yXnbHoncPpYL+db39mRlpoaPhrDl9KcKiGedVcl20=; b=MWpYbeetyTz1VpY4mkV7DIbGmyGoOH1qRFRQL4mANjCmiAbQGCIDvNaQHOEu7wQnjb6fl4 D6r4xlvjm5mZDoeEw4UpVrKcCKOd8K1JTNI6IOOuL528BREawsbgKcOLl+zxM+Zyi6+TNu giM51IhZnY35NqeS5nvMViz3azhB560= Received: from mail-oo1-f71.google.com (mail-oo1-f71.google.com [209.85.161.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-632-PHNNHb03PgOOQImyiMw6mQ-1; Mon, 29 Aug 2022 11:29:27 -0400 X-MC-Unique: PHNNHb03PgOOQImyiMw6mQ-1 Received: by mail-oo1-f71.google.com with SMTP id j9-20020a4ad2c9000000b004489186accbso3774003oos.4 for ; Mon, 29 Aug 2022 08:29:27 -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=N/yXnbHoncPpYL+db39mRlpoaPhrDl9KcKiGedVcl20=; b=P9+JphjFnJaXbVCRGKSFDrKbyXO/rYSjOI/i9XhoOXsrNLxeJqsOStsryfgjhTjgkH fBti7QuivgiuZW962pATEYxhC3sGRRArj/atvgoNvI87grv2r1jMPR4WOJ7mBMiHhXLP 71numFlPlu1P1tPAoiZi0t2ScPSLoGUPLBqPL8p+BQtT8jW6ePMp85alZHQE++RjRbqU lvJg3zMdY0MFuxJgupQQjcnyMcLjXe+xH4W9SmjXzgaWycJBxGZCT2GpmwmcGDWivOHo 6Ey7ptQKO9K7lklupHKHYxv1kHbB6Wp/G9h+OPR2Vnuc+oIx1LneeIQSaaYxGAbRt3CE gYBw== X-Gm-Message-State: ACgBeo0Hmq7Q7Bn2ApMIO0BbmlhMtezGDZPisR+nx/r6YLlhbAulMTkd za8Pyjd47q+P4kZs98/5R6xt+FQdyiu/aNlOM4sd4o+DrYxWog6BgimgudG6U0QdhXsG809dBx1 I4t4ob90A5SWoqP6buTZfMymazannu2nndw== X-Received: by 2002:a05:6870:210b:b0:10b:ed11:4e2d with SMTP id f11-20020a056870210b00b0010bed114e2dmr8157199oae.265.1661786966674; Mon, 29 Aug 2022 08:29:26 -0700 (PDT) X-Google-Smtp-Source: AA6agR6k9agcpuregJAkNxyhIH9pVQ5C3WBNVI/gX2vYKOv7We7rC2EBlK48txcF5juNayTsBeZrI2BGPX6R8/GP82Y= X-Received: by 2002:a05:6870:210b:b0:10b:ed11:4e2d with SMTP id f11-20020a056870210b00b0010bed114e2dmr8157193oae.265.1661786966452; Mon, 29 Aug 2022 08:29:26 -0700 (PDT) MIME-Version: 1.0 References: <20220826154606.1155977-1-aldyh@redhat.com> <616b4af5-e3b7-844e-5dcf-a73a5280d114@gmail.com> In-Reply-To: From: Aldy Hernandez Date: Mon, 29 Aug 2022 17:29:15 +0200 Message-ID: Subject: Re: [PATCH] [ranger] x == -0.0 does not mean we can replace x with -0.0 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.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE,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 Mon, Aug 29, 2022 at 5:08 PM Jeff Law wrote: > > > > 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. Absolutely. Just working with basic relationals I've noticed that we generate absolute garbage for some simple testcases. I'm amazed what makes it all the way to the assembly because we fail to fold simple things. Aldy