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 D88E83858C39 for ; Wed, 9 Nov 2022 13:14:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D88E83858C39 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=1667999673; 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=mkng43MC/5MdndualC/pBywhVjbN/kv+1rdrWupxB4M=; b=THMPjcfkjnIHhZiFDB7dWwW40YVxCv7Y/XEluF33iAN32LjokFdFksuh+aH7M6/Kw6ZGmJ drKNPqQ2KiTLjVusW6dNdtkGGJTSvJg2jh89tR5ZdXK1useMMd5MqhMjczBGjoL+oPrbQ2 AVsnfd0wuPlvuZgDKCYuvyJ1aazEvO0= Received: from mail-yb1-f200.google.com (mail-yb1-f200.google.com [209.85.219.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-38-ukwaQ_J9Mk-pFczYbQUmKA-1; Wed, 09 Nov 2022 08:14:32 -0500 X-MC-Unique: ukwaQ_J9Mk-pFczYbQUmKA-1 Received: by mail-yb1-f200.google.com with SMTP id y65-20020a25c844000000b006bb773548d5so16651990ybf.5 for ; Wed, 09 Nov 2022 05:14:32 -0800 (PST) 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:subject:date:message-id :reply-to; bh=mkng43MC/5MdndualC/pBywhVjbN/kv+1rdrWupxB4M=; b=Vsva22pCoZa33bX4aXKI+xSANV4Xd6pI3EMUmyggspH8RVZ8tvFz609gShQiEgvcV/ bF3rEl70WQWG8fVHQdOgPqtpt4Fw6bkev92scgg3kbFb41yqzDn1hBd8iQC+s3TlIALZ +d60/w0aD6e4AYtdRGnlWFg8lxRZxdcY6j1UjcfTJkONOdLz7HRadMQ6FviIzsE05VVX Mz9T573RIPIgECHH0WVqoPob+ErgoWvU+sfl3G0THhi6+hRmtNzpQ8xpTJhW5D6STIIq 4xTXHWGSBv2Q4bJIlskCErNGlYEPKeIEwSoHFYKE5kUHXJlIoAHzZU1IRK7NdN0gKIPd mVGA== X-Gm-Message-State: ACrzQf3ErsJSyuXNegUOfZ4qfzBb6Ufc1Di4d8s5DeuIcxlY9OJNe0z9 RqiAFPST+B1FJ+TgPb/+Hi0WdhMvpZwuxKDXnF4MjSwFzHNsqwurzQZYug52bPHTnnpGdEslr74 aqkSJg4LVZEA8+pbyrabdq3ApME/kRGAnzA== X-Received: by 2002:a0d:cdc2:0:b0:34d:101b:53c with SMTP id p185-20020a0dcdc2000000b0034d101b053cmr58985051ywd.444.1667999671869; Wed, 09 Nov 2022 05:14:31 -0800 (PST) X-Google-Smtp-Source: AMsMyM566ID2rLNb5Z2HKf7IVmM0TvegPmeeldg0szrp7w116ua8/GCnDemoPa3ttnMQL/fuO26oJ0fIwe4uxZtJs30= X-Received: by 2002:a0d:cdc2:0:b0:34d:101b:53c with SMTP id p185-20020a0dcdc2000000b0034d101b053cmr58985035ywd.444.1667999671598; Wed, 09 Nov 2022 05:14:31 -0800 (PST) MIME-Version: 1.0 References: <20221109070758.1030615-1-aldyh@redhat.com> In-Reply-To: From: Aldy Hernandez Date: Wed, 9 Nov 2022 14:14:19 +0100 Message-ID: Subject: Re: [COMMITTED] [range-op-float] Abstract out binary operator code out of PLUS_EXPR entry. To: Jakub Jelinek Cc: GCC patches , Andrew MacLeod X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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 Wed, Nov 9, 2022 at 1:48 PM Jakub Jelinek wrote: > > On Wed, Nov 09, 2022 at 08:07:57AM +0100, Aldy Hernandez wrote: > > The PLUS_EXPR was always meant to be a template for further > > development, since most of the binary operators will share a similar > > structure. This patch abstracts out the common bits into the default > > definition for range_operator_float::fold_range() and provides an > > rv_fold() to be implemented by the individual entries wishing to use > > the generic folder. This is akin to what we do with fold_range() and > > wi_fold() in the integer version of range-ops. > > Shouldn't foperator_mult be very similar to this (except that until > division is done op[12]_range can't be implemented), with the exception > that the invalid case isn't -INF + INF or INF + -INF, but > 0 * +/-INF or +/-INF * 0? Multiplication and division are tricky because you have to keep track of signs to order the resulting range. It's the most annoying pattern we have for integers: // Multiplications, divisions and shifts are a bit tricky to handle, // depending on the mix of signs we have in the two ranges, we need to // operate on different values to get the minimum and maximum values // for the new range. One approach is to figure out all the // variations of range combinations and do the operations. // // However, this involves several calls to compare_values and it is // pretty convoluted. It's simpler to do the 4 operations (MIN0 OP // MIN1, MIN0 OP MAX1, MAX0 OP MIN1 and MAX0 OP MAX0 OP MAX1) and then // figure the smallest and largest values to form the new range. But if you have a simpler approach, have at it. I may have to bail on multiplication and division for this cycle, cause I'm running out of cycles :-/. Hmmm...even if we don't get to implement mult/div in this cycle, perhaps we could at least figure out if we'll NAN as you've suggested above. So, set [-INF,+INF] but without a NAN when applicable. Aldy