From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw1-x1134.google.com (mail-yw1-x1134.google.com [IPv6:2607:f8b0:4864:20::1134]) by sourceware.org (Postfix) with ESMTPS id C93553852C68 for ; Thu, 24 Nov 2022 11:31:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C93553852C68 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-yw1-x1134.google.com with SMTP id 00721157ae682-39451671bdfso12918157b3.10 for ; Thu, 24 Nov 2022 03:31:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=s26Yq72HvQwVuemN9ZypwIPVAhp8NIj8Hc6x02ErUN8=; b=YzOejU2wfiQ/EvUHzDweN0udWjtiMiXHaJFuDqA1cSoaqzl9wCPLxIp1R5eqhMmr8V mJWYUuO/z7fEpoPMkm0BgHFrKySls1BLygUEMgPlYlhLx8b6uo5t01VrDPy+JdT51MzH 9+z1ws2YljbWDRi/2KNU4qlkem21DKB4mymA4KQhNSCCbD6S8zNTi3JH++ktQDUQR1Lg Iuu0tJ5v6FImFsD2oBvaQ9TFn1HXoxYniDe2XJ5OlWdYriHRexhsNrIIaHZih7X1vguD DTox8B0dOueigU97XbiOM9jb/Lm8x4jChFhAXJc80cSIKNU3q1fTRHEmzp5Y7nlZRgxw 3QbA== 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=s26Yq72HvQwVuemN9ZypwIPVAhp8NIj8Hc6x02ErUN8=; b=F3htP3Fj6R06T5tqN79Ei7sxdxVAOpCyUbS+Rf/g2ai01gBzK+ZG+Tla53jblq/9MK PkTJ6D8FsNgdGVZFeZYeFG3xalED4s9z+uuY2l7ie+s+FBRW8epRXk1SelUs1HhrVP0W ENURlpSLXYZMe1f68Z7o1xhj3I3bPEDFkHbqawbFpLE4dc8V9E24CW+pFbJBSgkAvw1z EPeat7/8efBDXNiUoAt8BCDKgYLp0b1pa5zYUduvubxAQo6AQ7WHwV10pPscSU4592Fm Wg+flXoeGMhMwSX5MThcf7xRZijuhAz1uGyAsq5irL2MO1CfyaYsO/fWxd8JGRWB5CLm Y+PA== X-Gm-Message-State: ANoB5plpFKR5qJO2yTkWJ4qFr1Iz5ZuXECumppXMBkSdJz2t5W2BUL74 iZ7RC9Iv8k0EEkInJ9jl0OkhjuRJGjq7XqIDPlw= X-Google-Smtp-Source: AA0mqf4xo0G+qh8iPapcOisWSRAaQM29nbZuoQ9E45vouIqDyJbm6gpDaitoXxO6hti3yaTHJMO3ZRLmSumX7jH215I= X-Received: by 2002:a81:552:0:b0:367:b4b3:3952 with SMTP id 79-20020a810552000000b00367b4b33952mr31662338ywf.508.1669289464190; Thu, 24 Nov 2022 03:31:04 -0800 (PST) MIME-Version: 1.0 References: <20221124012200.103783-1-hongtao.liu@intel.com> In-Reply-To: From: Hongtao Liu Date: Thu, 24 Nov 2022 19:30:52 +0800 Message-ID: Subject: Re: [PATCH v2] [x86] Fix incorrect _mm_cvtsbh_ss. To: Jakub Jelinek Cc: liuhongt , gcc-patches@gcc.gnu.org, hjl.tools@gmail.com, ubizjak@gmail.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,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 4:53 PM Jakub Jelinek wrote: > > 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. I'll remove flag_signaling_nans. > > 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 Oh, good to know that, thanks. > optimize_function_for_{size,speed}_p (cfun) > so maybe fast math related stuff is fine, just not the optimization for > speed or size. I saw many backends(riscv,rs6000,mips,loongarch) already used HONOR_* stuff in the expander conditions. > > Jakub > -- BR, Hongtao