From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) by sourceware.org (Postfix) with ESMTPS id 78F5C3858D28 for ; Wed, 21 Jun 2023 11:07:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 78F5C3858D28 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-lj1-x234.google.com with SMTP id 38308e7fff4ca-2b475b54253so51909111fa.2 for ; Wed, 21 Jun 2023 04:07:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687345646; x=1689937646; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Z2Uy7ttFtQGRlD1+sotS8jni4/ztChEJXwlkuoUdLX0=; b=AaoX/yiSjWs2F3T3erv25W/qgBKncsTBlpqztmD4Q3XbtbXsvPeETXQpQ4JU/2YSaW WuEPFKoLn38R06NoSovrIBcmyFmdOX1QIn6qDfnEx6EZPu/9cugjsBAfOmI0Fwc+jyVo YFHGWK3mR13g1S/6phAdE9BfIABrUmtpa33sIr4doNF5uxE2MDAcu8Ecbs8eovjVIllq bYrZjz0ygZz/Xwq8atJJEMelRqAyS0meh0vsr6rRrNE2OrqdXNQ9wcoPq7DgWHUzY4vO EpTv+3laXWMV6HuXo372jJeBfZK/5py4j+yK+GIo7lT+UauBi4UHxPCMYJFYM8INQezH pcig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687345646; x=1689937646; h=content-transfer-encoding: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=Z2Uy7ttFtQGRlD1+sotS8jni4/ztChEJXwlkuoUdLX0=; b=IhEC2nO8Xac7bwTy3I+vnEJOozLXw8iToCw/gLO7oG1VOXco2+5pgQ+0q8S3M7Hwzs RuwPkcg2PLnJn8Sdrcvqoe0KMTeAy9zPpra3JLmDFvjJRExZt8w/vidQJnL3Prxetkpq Maf5aFf08GJhkpQ9+Daq3JCzKRXQmkNVMhiuz0yp2mAe1d1gQIY/h49nr/7jzjOJV9v4 U714ozVt9rTIl+x9lt++zPM81Chmkj0/IXneaV0TnyYVL12mvylsBChZDUv7IicQGQU+ bFXexXBotGPvzTvxjmeL/oaO4/nZp0pnyOVnWn3MVrcRvMt/h+K8V/LPjr6bivh2YsPM 17Lw== X-Gm-Message-State: AC+VfDy0Cqhqw9hu4bp3Xu+z2n/NaFsQWNx+z6fiyOcMbk6Mmv04DZqH X+P0A5mpUrnY0/dAN+BNC+7dNAQ9rjCh1wcCGNHvQmQW X-Google-Smtp-Source: ACHHUZ7Nw/bfSgtzSCWTGEv1RAV7XG1fE+6brcklY76c0/qe/u5XjY7JrYzr/zUS0iDXkmo7zIEKrTmGZwvx2UqFLOw= X-Received: by 2002:a2e:8683:0:b0:2b3:2f9b:7c99 with SMTP id l3-20020a2e8683000000b002b32f9b7c99mr9073124lji.14.1687345645491; Wed, 21 Jun 2023 04:07:25 -0700 (PDT) MIME-Version: 1.0 References: <20230602010015.2571612-1-hongtao.liu@intel.com> In-Reply-To: From: Richard Biener Date: Wed, 21 Jun 2023 13:04:28 +0200 Message-ID: Subject: Re: [PATCH] [vect]Use intermiediate integer type for float_expr/fix_trunc_expr when direct optab is not existed. To: Richard Biener via Gcc-patches , liuhongt , Richard Biener , crazylht@gmail.com, hjl.tools@gmail.com, richard.sandiford@arm.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-7.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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, Jun 21, 2023 at 11:32=E2=80=AFAM Richard Sandiford wrote: > > Richard Sandiford writes: > > Richard Biener via Gcc-patches writes: > >> On Fri, Jun 2, 2023 at 3:01=E2=80=AFAM liuhongt via Gcc-patches > >> wrote: > >>> > >>> We have already use intermidate type in case WIDEN, but not for NONE, > >>> this patch extended that. > >>> > >>> I didn't do that in pattern recog since we need to know whether the > >>> stmt belongs to any slp_node to decide the vectype, the related optab= s > >>> are checked according to vectype_in and vectype_out. For non-slp case= , > >>> vec_pack/unpack are always used when lhs has different size from rhs, > >>> for slp case, sometimes vec_pack/unpack is used, somethings > >>> direct conversion is used. > >>> > >>> Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}. > >>> Ok for trunk? > >>> > >>> gcc/ChangeLog: > >>> > >>> PR target/110018 > >>> * tree-vect-stmts.cc (vectorizable_conversion): Use > >>> intermiediate integer type for float_expr/fix_trunc_expr when > >>> direct optab is not existed. > >>> > >>> gcc/testsuite/ChangeLog: > >>> > >>> * gcc.target/i386/pr110018-1.c: New test. > >>> --- > >>> gcc/testsuite/gcc.target/i386/pr110018-1.c | 94 ++++++++++++++++++++= ++ > >>> gcc/tree-vect-stmts.cc | 56 ++++++++++++- > >>> 2 files changed, 149 insertions(+), 1 deletion(-) > >>> create mode 100644 gcc/testsuite/gcc.target/i386/pr110018-1.c > >>> > >>> diff --git a/gcc/testsuite/gcc.target/i386/pr110018-1.c b/gcc/testsui= te/gcc.target/i386/pr110018-1.c > >>> new file mode 100644 > >>> index 00000000000..b1baffd7af1 > >>> --- /dev/null > >>> +++ b/gcc/testsuite/gcc.target/i386/pr110018-1.c > >>> @@ -0,0 +1,94 @@ > >>> +/* { dg-do compile } */ > >>> +/* { dg-options "-mavx512fp16 -mavx512vl -O2 -mavx512dq" } */ > >>> +/* { dg-final { scan-assembler-times {(?n)vcvttp[dsh]2[dqw]} 5 } } *= / > >>> +/* { dg-final { scan-assembler-times {(?n)vcvt[dqw]*2p[dsh]} 5 } } *= / > >>> + > >>> +void > >>> +foo (double* __restrict a, char* b) > >>> +{ > >>> + a[0] =3D b[0]; > >>> + a[1] =3D b[1]; > >>> +} > >>> + > >>> +void > >>> +foo1 (float* __restrict a, char* b) > >>> +{ > >>> + a[0] =3D b[0]; > >>> + a[1] =3D b[1]; > >>> + a[2] =3D b[2]; > >>> + a[3] =3D b[3]; > >>> +} > >>> + > >>> +void > >>> +foo2 (_Float16* __restrict a, char* b) > >>> +{ > >>> + a[0] =3D b[0]; > >>> + a[1] =3D b[1]; > >>> + a[2] =3D b[2]; > >>> + a[3] =3D b[3]; > >>> + a[4] =3D b[4]; > >>> + a[5] =3D b[5]; > >>> + a[6] =3D b[6]; > >>> + a[7] =3D b[7]; > >>> +} > >>> + > >>> +void > >>> +foo3 (double* __restrict a, short* b) > >>> +{ > >>> + a[0] =3D b[0]; > >>> + a[1] =3D b[1]; > >>> +} > >>> + > >>> +void > >>> +foo4 (float* __restrict a, char* b) > >>> +{ > >>> + a[0] =3D b[0]; > >>> + a[1] =3D b[1]; > >>> + a[2] =3D b[2]; > >>> + a[3] =3D b[3]; > >>> +} > >>> + > >>> +void > >>> +foo5 (double* __restrict b, char* a) > >>> +{ > >>> + a[0] =3D b[0]; > >>> + a[1] =3D b[1]; > >>> +} > >>> + > >>> +void > >>> +foo6 (float* __restrict b, char* a) > >>> +{ > >>> + a[0] =3D b[0]; > >>> + a[1] =3D b[1]; > >>> + a[2] =3D b[2]; > >>> + a[3] =3D b[3]; > >>> +} > >>> + > >>> +void > >>> +foo7 (_Float16* __restrict b, char* a) > >>> +{ > >>> + a[0] =3D b[0]; > >>> + a[1] =3D b[1]; > >>> + a[2] =3D b[2]; > >>> + a[3] =3D b[3]; > >>> + a[4] =3D b[4]; > >>> + a[5] =3D b[5]; > >>> + a[6] =3D b[6]; > >>> + a[7] =3D b[7]; > >>> +} > >>> + > >>> +void > >>> +foo8 (double* __restrict b, short* a) > >>> +{ > >>> + a[0] =3D b[0]; > >>> + a[1] =3D b[1]; > >>> +} > >>> + > >>> +void > >>> +foo9 (float* __restrict b, char* a) > >>> +{ > >>> + a[0] =3D b[0]; > >>> + a[1] =3D b[1]; > >>> + a[2] =3D b[2]; > >>> + a[3] =3D b[3]; > >>> +} > >>> diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc > >>> index bd3b07a3aa1..1118c89686d 100644 > >>> --- a/gcc/tree-vect-stmts.cc > >>> +++ b/gcc/tree-vect-stmts.cc > >>> @@ -5162,6 +5162,49 @@ vectorizable_conversion (vec_info *vinfo, > >>> return false; > >>> if (supportable_convert_operation (code, vectype_out, vectype_= in, &code1)) > >>> break; > >> > >> A comment would be nice here. Like > >> > >> /* For conversions between float and smaller integer types try whet= her we can > >> use intermediate signed integer types to support the conversion.= */ > >> > >>> + if ((code =3D=3D FLOAT_EXPR > >>> + && GET_MODE_SIZE (lhs_mode) > GET_MODE_SIZE (rhs_mode)) > >>> + || (code =3D=3D FIX_TRUNC_EXPR > >>> + && GET_MODE_SIZE (rhs_mode) > GET_MODE_SIZE (lhs_mode))= ) > > > > Is the FIX_TRUNC_EXPR case safe without some flag? > > > > #include > > int32_t x =3D (int32_t)0x1.0p32; > > int32_t y =3D (int32_t)(int64_t)0x1.0p32; > > > > sets x to 2147483647 and y to 0. Hmm, good question. GENERIC has a direct truncation to unsigned char for example, the C standard generally says if the integral part cannot be represented then the behavior is undefined. So I think we should be safe here (0x1.0p32 doesn't fit an int). > Also, I think multi_step_cvt should influence the costs, since at > the moment we cost one statement but generate two. This makes a > difference for SVE with VECT_COMPARE_COSTS. Would changing it to: > > vect_model_simple_cost (vinfo, stmt_info, > ncopies * (multi_step_cvt + 1), > dt, ndts, slp_node, > cost_vec); > > be OK? Yeah, I guess so. > There again, I wonder if we should handle this using patterns instead. > That makes both conversions explicit and therefore easier to cost. But we don't do this for the other multi-step conversions either ... but sure, I also suggested that but the complaint was that with BB SLP this would get us a vector type with off lanes? > E.g. for SVE, an integer extension is free if the source is a load, > and we do try to model that. But it's difficult to handle if the > conversion is only implicit. In the distant future I hope that vectorizable_conversion will upon analysis produce an SLP sub-graph for the suggested code generation which we'd then cost. My current idea is to get this part live before switching the analysis to all-SLP because it "seems" easier (fingers crossing). Still I'm struggling to even find time to start that effort. Richard. > > Thanks, > Richard