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 1CC60384BC3A for ; Fri, 11 Nov 2022 02:06:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1CC60384BC3A 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=1668132416; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=smax9KpFUbdov7OMXRBU3BDvEO3rrClt8etFX6j8oRI=; b=bGAnMZr74d2LwD5FYn1SVWFj0JBH2do5bZszaO/nD50SnV6HI5iROwxGLZqkkadBR3PzoM IV32a5amfITgcVy8aj23xo+pBa/UIPzjmGy/x4eNHWWtOO5Y5mt8pCTz0PzJi/4XOJXU7v ngyi2KfU2FhXudQJtGjbWrxJkKcnfo8= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-197-9qyCb6yHPCO62yqOw04eDg-1; Thu, 10 Nov 2022 21:06:55 -0500 X-MC-Unique: 9qyCb6yHPCO62yqOw04eDg-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 2812229AB44A for ; Fri, 11 Nov 2022 02:06:55 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.38]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D8475C15BA8; Fri, 11 Nov 2022 02:06:54 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 2AB26qXp3241273 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 11 Nov 2022 03:06:52 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 2AB26pc73241272; Fri, 11 Nov 2022 03:06:51 +0100 Date: Fri, 11 Nov 2022 03:06:51 +0100 From: Jakub Jelinek To: Aldy Hernandez , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] range-op: Implement floating point multiplication fold_range [PR107569] Message-ID: Reply-To: Jakub Jelinek References: <7304acea-b8bb-c930-546a-db6e3b3ff96b@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.8 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-3.9 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 Thu, Nov 10, 2022 at 08:20:06PM +0100, Jakub Jelinek via Gcc-patches wrote: > So, maybe for now a selftest will be better than a testcase, or > alternatively a plugin test which acts like a selftest. For a testsuite/g*.dg/plugin/ range-op-plugin.c test, would be nice to write a short plugin that does: 1) register 2 new attributes, say gcc_range and gcc_expected_range, parse their arguments 2) registers some new pass (dunno where it would be best, say before evrp or so), which would: - for function parameters with gcc_range attributes set global? range on default def of that parameter - if function itself has a gcc_expected_range attribute, propagate ranges from arguments to the function result and compare against gcc_expected_range - if function itself has gcc_range attribute and one of the arguments gcc_expected_range itself, try to propagate range backwards from result to the argument Then we could say write tests like: __attribute__((gcc_expected_range (12.0, 32.0, 0))) double foo (double x __attribute__((gcc_range (2.0, 4.0, 0))), double y __attribute__((gcc_range (6.0, 8.0, 0)))) { return x * y; } with for floating point types (parameter type or function result type) the arguments of the attribute being (constant folded) low bound, high bound, integer about NAN (say 0 meaning clear_nan, bit 0 meaning +NAN, bit 1 -NAN, bit 2 meaning known NAN (then the 2 bounds would be ignored)). Eventually we could do something similar for integral types, pointer types etc. I think this would be far more useful compared to writing selftests for it, and compared to the testcase I've posted would be easier to request or check exact range rather than a rough range. And we could easily test not just very simple binary ops (in both directions), but builtin calls etc. Thoughts on this? I can try to write a plugin that registers the attributes, parses them and registers a pass, but would appreciate your or Andrew's help in filling the actual pass. Jakub