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 A2B3C395B803 for ; Wed, 12 Oct 2022 10:57:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A2B3C395B803 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=1665572248; h=from:from:reply-to: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=FfouVQ2wSgfKYrAGebMeDmemBBarkJfIT6r4HTAlpYU=; b=SNQpWJ0NwoLbEqP/t9UccQv8GODRwAmW4v43OK6ocI112ehYeqflr3XfdctHnO8tBknJ6b dNKYkYIA74gxGql5lGzgfLaLbuspk35tG2eoLhquHNupUIaB9USjbfqLvNF/3P5ir01tf6 7ELQncZOrMBBs5D5aWUALWuxdThpn08= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-102-ttgUmE1DO6u29LUqDya_eQ-1; Wed, 12 Oct 2022 06:57:25 -0400 X-MC-Unique: ttgUmE1DO6u29LUqDya_eQ-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 0CF72185A792; Wed, 12 Oct 2022 10:57:25 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.55]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B6CBDC15BA4; Wed, 12 Oct 2022 10:57:24 +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 29CAvLom848684 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 12 Oct 2022 12:57:21 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 29CAvJTt848683; Wed, 12 Oct 2022 12:57:19 +0200 Date: Wed, 12 Oct 2022 12:57:19 +0200 From: Jakub Jelinek To: Eric Botcazou Cc: Jason Merrill , Richard Biener , Jeff Law , Richard Sandiford , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] machmode: Introduce GET_MODE_NEXT_MODE with previous GET_MODE_WIDER_MODE meaning, add new GET_MODE_WIDER_MODE Message-ID: Reply-To: Jakub Jelinek References: <95f2abba-afb4-bb73-a9f0-b1578b28713a@redhat.com> <3193881.aeNJFYEL58@fomalhaut> MIME-Version: 1.0 In-Reply-To: <3193881.aeNJFYEL58@fomalhaut> 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.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,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, Oct 12, 2022 at 12:37:39PM +0200, Eric Botcazou wrote: > > Though I admit I didn't go carefully through all 24 GET_MODE_WIDER_MODE > > uses, 54 FOR_EACH_MODE_IN_CLASS uses, 3 FOR_EACH_MODE uses, 24 > > FOR_EACH_MODE_FROM, 6 FOR_EACH_MODE_UNTIL and 15 FOR_EACH_WIDER_MODE uses. > > It is more important to go through the GET_MODE_WIDER_MODE and > > FOR_EACH_WIDER_MODE uses because the patch changes behavior for those, > > the rest keep their previous meaning and so can be changed incrementally > > if the other meaning is desirable to them (I've of course changed the 3 > > spots I had to change in the previous BFmode patch and whatever triggered > > during the bootstraps). > > > > Thoughts on this? > > Can't we declare that one is wider than the other, for example BFmode since it > has got a larger range? Though I guess this would mean special-casing them in > genmodes.cc as they are presumably strictly identical except for the format. That doesn't work, one of the modes has larger range, the other has larger floating point precision. So, neither of the modes is a subset or superset of the other. If we don't handle a particular optab for one of these modes and allow widening, for both of these modes we want to try SFmode next (which is a true superset of both modes, it has the same range as BFmode but higher floating point precision than both HFmode and BFmode). The only way to work around this widening problem would be always make sure that whenever we implement any optab for HFmode, we also implement the same optab for BFmode under exact same conditions and vice versa, even if those optabs just do by hand whatever the generic code would do if the optab didn't exist. But that is way too limiting. It is true that on PowerPC we have a similar situation for the widest floating point modes, TFmode/IFmode/KFmode and the backend has the ugly hack of pretending they have different GET_MODE_PRECISION, but as those are the widest modes and are implemented in hardware or in software emulation, they have in the backends the same optabs implemented. While for HFmode/BFmode, very few optabs are actually implemented directly and the usual intended use is performing most arithmetics in SFmode. Even on PowerPC, ibm_extended_format and ieee_quad_format are neither subset nor superset of each other, the latter has larger range and in most cases higher floating point precision, but the former for certain values can have even 10 times higher floating point precision. Jakub