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.129.124]) by sourceware.org (Postfix) with ESMTPS id D06773854567 for ; Mon, 5 Dec 2022 09:54:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D06773854567 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=1670234088; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/U44pqPfpwxSoBXCSeI7mG8nG2Zvab1qW5PcJqIktGw=; b=iPZbFXtEVK/iYFZDgHB9iZ6grn9eMqmA83dT3MiJi4lMNQ2JA44+qmFjBH6VbfzTD+X+9k QBX3JK2BbVVoBZA6w7q9Qx/eEG25KrmuupQC7UnPm2wn7yZRFP+tg7RWvVpytuvjgXkguB 3nufjWwIOZRm9jlxrwXTWIqcI8PASh8= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-673-nsuYTAwyODmBHjjz-1El6g-1; Mon, 05 Dec 2022 04:54:47 -0500 X-MC-Unique: nsuYTAwyODmBHjjz-1El6g-1 Received: by mail-wm1-f72.google.com with SMTP id o5-20020a05600c510500b003cfca1a327fso6611826wms.8 for ; Mon, 05 Dec 2022 01:54:47 -0800 (PST) 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:subject:date:message-id:reply-to; bh=/U44pqPfpwxSoBXCSeI7mG8nG2Zvab1qW5PcJqIktGw=; b=sDKf+o4ZRiXG3q6qsaoQKqx5+Uh3zCM9vCdePneTFsZSQ+Rh3EA4j8Sbjdg5FvWRU6 kNTGkp4333v+ZfAcC/8rdTMdaS8LMJGyfj4ZxADP30neYSPrYGe8KVpV+t6RRAHxatly dAzPnAuqyKQHOtYnyfEatCakhCWYxdjlQxrfCo73YaWMLLNfE8dbrtCsDZC4D0hCgRiz fmFpplRXnwZof9iJLaw3GMLhtg8ujWOmOJlbd5+k+mlEwoFp0tYIU4lgtHb9lnIfAAMH cuUrGfQtTfK683VVMMtuLE/xcfNtO9PPUd+zHKj9ZQfbmSe4KF6P2bc/Qk1TUpWVdc3O MQ1Q== X-Gm-Message-State: ANoB5pmHY42MiIpKQ3S4QXi+siQymdNZ6PpubgtZHXLG4DWQ3rV4Ll6k xFPmoMVe9DIFGmK5R6l4uIvb+qHTUTFpStFqI0Bqlq20SRNgm2t214kftAqDLMYf6+3A0qqaWkA NuhYG4gLS948kQjdeCQ== X-Received: by 2002:a7b:c8c3:0:b0:3cf:b49e:1638 with SMTP id f3-20020a7bc8c3000000b003cfb49e1638mr48661961wml.50.1670234086162; Mon, 05 Dec 2022 01:54:46 -0800 (PST) X-Google-Smtp-Source: AA0mqf7hHjrg288fPTu1cjUssy8ZbVGAu+egPaL0ReirVy5tpf1ZpQBReOOUhiJqmrhz6Tkj7MLqhQ== X-Received: by 2002:a7b:c8c3:0:b0:3cf:b49e:1638 with SMTP id f3-20020a7bc8c3000000b003cfb49e1638mr48661948wml.50.1670234085922; Mon, 05 Dec 2022 01:54:45 -0800 (PST) Received: from [192.168.100.171] (128.red-81-33-16.staticip.rima-tde.net. [81.33.16.128]) by smtp.gmail.com with ESMTPSA id c2-20020a05600c0a4200b003cfd4cf0761sm22713468wmq.1.2022.12.05.01.54.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Dec 2022 01:54:45 -0800 (PST) Message-ID: Date: Mon, 5 Dec 2022 10:54:41 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: [PATCH] range-op-float: Fix up multiplication and division reverse operation [PR107879] To: Jakub Jelinek Cc: gcc-patches@gcc.gnu.org, Andrew MacLeod References: <1f2b50a8-8f3c-690a-182b-c636fc2f86ed@redhat.com> From: Aldy Hernandez In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP 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 12/5/22 10:37, Jakub Jelinek wrote: > On Mon, Dec 05, 2022 at 10:20:53AM +0100, Aldy Hernandez wrote: >>> For the division, [-0., 0.] / VARYING is computed (IMHO correctly) >>> as [-0., 0.] +-NAN, because 0 / anything but 0 or NAN is still >>> 0 and 0 / 0 is NAN and ditto 0 / NAN. And then we just >>> float_binary_op_range_finish, which figures out that because lhs >>> can't be NAN, neither operand can be NAN. So, the end range is >>> [-0., 0.]. But that is not correct for the reverse multiplication. >>> When the result is 0, if op2 can be zero, then x can be anything >>> (VARYING), to be precise anything but INF (unless result can be NAN), >> >> Not an objection, just an observation... If we know it can't be INF, could >> we drop INF from the range? We have frange_drop_{inf,ninf} for this. > > Do you mind if I try that incrementally and only if it doesn't make the > code too large/too unreadable? Sure. And don't feel obligated to implement it either. range-ops is a never ending pit of possible optimizations. We found that out quite early in the design. If you don't get to it, could you at least add a comment? Aldy > >>> + // If both lhs and op2 could be zeros or both could be infinities, >>> + // we don't know anything about op1 except maybe for the sign >>> + // and perhaps if it can be NAN or not. >>> + REAL_VALUE_TYPE lb, ub; >>> + int signbit_known = signbit_known_p (lhs_lb, lhs_ub, op2_lb, op2_ub); >>> + zero_to_inf_range (lb, ub, signbit_known); >>> + r.set (type, lb, ub); >> >> I assume we don't know anything about the sign of the NAN because of all the >> weird IEEE rules? > > Yes, sign bit of NAN is unknown after binary operation or even in the > reverse case of binary operations. > The sign rule is for non-NAN. > > "When neither the inputs nor result are NaN, the sign of a product or quotient is the exclusive OR of the > operands' signs; the sign of a sum, or of a difference x–y regarded as a sum x+(–y), differs from at most one of > the addends' signs; and the sign of the result of the roundToIntegral operations and roundToIntegralExact (see > 7.3.1) is the sign of the operand. These rules shall apply even when operands or results are zero or > infinite." > > Jakub >