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 825AC38432E6 for ; Thu, 24 Nov 2022 08:53:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 825AC38432E6 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=1669280008; 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=jDilJ7RXsoCnqD7qmrAaC43JwJeFR6akWriiwPSXNaw=; b=A9rv3IavlGGLnM9iaMQskcnoV/upj16Rc+R47h8nd8B1GWs5bb2xxAIMdAHkV9ySh4D61X qusBYZZI9jV9hku4xO6WU20Lr6XW54OuEbWOYvYQS6qFtzEfQXalDDwQuRiCSo1kENNhNd 7oJ8YhbJ3rKiP/OLAcmLDmfwGQ2sk7k= 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-438-UVoLGsbVNl-fAmwijh1NUw-1; Thu, 24 Nov 2022 03:53:26 -0500 X-MC-Unique: UVoLGsbVNl-fAmwijh1NUw-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 57D1D2A5957D; Thu, 24 Nov 2022 08:53:26 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.194.202]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1933117585; Thu, 24 Nov 2022 08:53:25 +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 2AO8rL6Q222155 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 24 Nov 2022 09:53:21 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 2AO8rJjL222154; Thu, 24 Nov 2022 09:53:19 +0100 Date: Thu, 24 Nov 2022 09:53:19 +0100 From: Jakub Jelinek To: liuhongt Cc: gcc-patches@gcc.gnu.org, crazylht@gmail.com, hjl.tools@gmail.com, ubizjak@gmail.com Subject: Re: [PATCH v2] [x86] Fix incorrect _mm_cvtsbh_ss. Message-ID: Reply-To: Jakub Jelinek References: <20221124012200.103783-1-hongtao.liu@intel.com> MIME-Version: 1.0 In-Reply-To: <20221124012200.103783-1-hongtao.liu@intel.com> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.5 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 24, 2022 at 09:22:00AM +0800, liuhongt via Gcc-patches wrote: > --- a/gcc/config/i386/i386.md > +++ b/gcc/config/i386/i386.md > @@ -130,6 +130,7 @@ (define_c_enum "unspec" [ > ;; For AVX/AVX512F support > UNSPEC_SCALEF > UNSPEC_PCMP > + UNSPEC_CVTBFSF > > ;; Generic math support > UNSPEC_IEEE_MIN ; not commutative > @@ -4961,6 +4962,31 @@ (define_insn "*extendhf2" > (set_attr "prefix" "evex") > (set_attr "mode" "")]) > > +(define_expand "extendbfsf2" > + [(set (match_operand:SF 0 "register_operand") > + (unspec:SF > + [(match_operand:BF 1 "register_operand")] > + UNSPEC_CVTBFSF))] > + "TARGET_SSE2 && !HONOR_NANS (BFmode) && !flag_signaling_nans") I think if !HONOR_NANS (BFmode), then flag_signaling_nans doesn't matter, the former says that no NaNs may appear in a valid program, so just testing !HONOR_NANS (BFmode) should be enough. What I'm not sure about, my memory is weak, is whether one can safely use the fast math related tests in define_expand conditions. I vaguely remember init_all_optabs remembers the conditions, for changes say in the ISA options optabs are reinited, but not sure if that happens for optimization option changes like the fast math related options are. So it would be perhaps safer to use just TARGET_SSE2 as the expand condition and in the C code body do if (HONOR_NANS (BFmode) FAIL; (similarly for truncsfbf2). On the other side brief look at x86 insn-flags.h shows several fast math related checks in HAVE_* macros. PR92791 I found related to this was actually about optimize_function_for_{size,speed}_p (cfun) so maybe fast math related stuff is fine, just not the optimization for speed or size. Jakub