From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) by sourceware.org (Postfix) with ESMTPS id 879DC3858D32 for ; Wed, 19 Jul 2023 08:29:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 879DC3858D32 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-x22d.google.com with SMTP id 38308e7fff4ca-2b9540031acso22831191fa.3 for ; Wed, 19 Jul 2023 01:29:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689755366; x=1692347366; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=iMdu76xYAAosHCqxAr4e+U4y578N4DvWoAJItyT8OSY=; b=dXvFVD3mVEE2OB5uf+/OcNQk1k6k4I6FDHU4IUTGE3ga5yyEoPKNXp/6qoyxE1ioCr 41F3/vwbfvdxi7G1x3B9oBVQFEno1EZG4bd2tSyH2jbVvRM3lHMMFo9j3sahr2duYYem YNqxClpOeISmEAiuODQlGi8hS5ohcy2SyOJPlwo2EZNZbbxNHdyRZHbIGmpF5EbcXZBS ag0s7WTkakrfJ0GfdK3CQ1q46MpkBd48Fuam/XTEO9GSd01NBcdUr0DONYlkwO+KzXYq ANLPW/JLuAXmxX7yU8w/SuLVbTJlTBzTMBJ2rd0umTSJ/736OTbAE1k0XOhKPNDsorxA htLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689755366; x=1692347366; h=content-transfer-encoding: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=iMdu76xYAAosHCqxAr4e+U4y578N4DvWoAJItyT8OSY=; b=C1197VzQdNnzQffS3QxN5iNlJN6R7VC9p8/V3v5fJQsTVm23VBZWj8I14lrjDKUGAj Z7EOsBMl5r4KDUh7fx1OHYpSmYxaq2QJ6EfNM1MAcl8lNwayb5wqbzMrn5St4CWo9t7T X9PaK6H/L5c+2a6/42RgrI4fV/sn82BDM/4na80xknT1MengwnFFIUkKZ3oP8PGojYJz eP5ciqBjGeu5lDaMttKNK/Q5Ta4IrBALHdTdu7ebDvuK8wQblpZBgiUOZpxm9Xlpfd9U dzsoLSqvGRnqZMR0GKlXb3mKmcnPtbXGZ191wMT4J8e/nIHuWkOlvylQWs0yZZR+GehK WBDQ== X-Gm-Message-State: ABy/qLbBbb+MkpmGulKb8w4v7QwUCbIy8YC2y8ss2uxi4k09BgjlyQzP OpUTjX1AgwGhtNiOKXGLi1HnvdJ2gvDl+A/4qmFgKlxn X-Google-Smtp-Source: APBJJlH7LNeLZREpmnC9pQduZrkngGj2frTx0bMMJMP+dI0VQb85IuvIoQ1d6rhsepc0rmByamJwIwW92Jqrvjjiw7s= X-Received: by 2002:a2e:97d2:0:b0:2b6:daed:494f with SMTP id m18-20020a2e97d2000000b002b6daed494fmr12325515ljj.35.1689755365735; Wed, 19 Jul 2023 01:29:25 -0700 (PDT) MIME-Version: 1.0 References: <632f5e92-f1b7-816f-3f16-9ba09e53c5ab@gmail.com> In-Reply-To: <632f5e92-f1b7-816f-3f16-9ba09e53c5ab@gmail.com> From: Richard Biener Date: Wed, 19 Jul 2023 10:28:52 +0200 Message-ID: Subject: Re: [PATCH v2] vect: Handle demoting FLOAT and promoting FIX_TRUNC. To: Robin Dapp Cc: gcc-patches Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-7.5 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 Fri, Jul 14, 2023 at 5:16=E2=80=AFPM Robin Dapp wr= ote: > > >>> Can you add testcases? Also the current restriction is because > >>> the variants you add are not always correct and I don't see any > >>> checks that the intermediate type doesn't lose significant bits? > > I didn't manage to create one for aarch64 nor for x86 because AVX512 > has direct conversions e.g. for int64_t -> _Float16 and the new code > will not be triggered. Instead I added two separate RISC-V tests. > > The attached V2 always checks trapping_math when converting float > to integer and, like the NARROW_DST case, checks if the operand fits > the intermediate type when demoting from int to float. > > Would that be sufficient? > > riscv seems to be the only backend not (yet?) providing pack/unpack > expanders for the vect conversions and rather relying on extend/trunc > which seems a disadvantage now, particularly for the cases requiring > !flag_trapping_math with NONE but not for NARROW_DST. That might > be reason enough to implement pack/unpack in the backend. > > Nevertheless the patch might improve the status quo a bit? > > Regards > Robin > > > The recent changes that allowed multi-step conversions for > "non-packing/unpacking", i.e. modifier =3D=3D NONE targets included > promoting to-float and demoting to-int variants. This patch > adds the missing demoting to-float and promoting to-int handling. > > gcc/ChangeLog: > > * tree-vect-stmts.cc (vectorizable_conversion): Handle > more demotion/promotion for modifier =3D=3D NONE. > > gcc/testsuite/ChangeLog: > > * gcc.target/riscv/rvv/autovec/conversions/vec-narrow-int64-float= 16.c: New test. > * gcc.target/riscv/rvv/autovec/conversions/vec-widen-float16-int6= 4.c: New test. > --- > .../conversions/vec-narrow-int64-float16.c | 12 ++++ > .../conversions/vec-widen-float16-int64.c | 12 ++++ > gcc/tree-vect-stmts.cc | 58 +++++++++++++++---- > 3 files changed, 71 insertions(+), 11 deletions(-) > create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/conversion= s/vec-narrow-int64-float16.c > create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/conversion= s/vec-widen-float16-int64.c > > diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/conversions/vec-n= arrow-int64-float16.c b/gcc/testsuite/gcc.target/riscv/rvv/autovec/conversi= ons/vec-narrow-int64-float16.c > new file mode 100644 > index 00000000000..ebee1cfa888 > --- /dev/null > +++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/conversions/vec-narrow-i= nt64-float16.c > @@ -0,0 +1,12 @@ > +/* { dg-do compile } */ > +/* { dg-additional-options "-std=3Dc99 -fno-vect-cost-model -march=3Drv6= 4gcv_zvfh -mabi=3Dlp64d --param=3Driscv-autovec-preference=3Dscalable" } */ > + > +#include > + > +void convert (_Float16 *restrict dst, int64_t *restrict a, int n) > +{ > + for (int i =3D 0; i < n; i++) > + dst[i] =3D (_Float16) (a[i] & 0x7fffffff); > +} > + > +/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" } } *= / > diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/conversions/vec-w= iden-float16-int64.c b/gcc/testsuite/gcc.target/riscv/rvv/autovec/conversio= ns/vec-widen-float16-int64.c > new file mode 100644 > index 00000000000..eb0a17e99bc > --- /dev/null > +++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/conversions/vec-widen-fl= oat16-int64.c > @@ -0,0 +1,12 @@ > +/* { dg-do compile } */ > +/* { dg-additional-options "-std=3Dc99 -fno-vect-cost-model -march=3Drv6= 4gcv_zvfh -mabi=3Dlp64d --param=3Driscv-autovec-preference=3Dscalable -fno-= trapping-math" } */ > + > +#include > + > +void convert (int64_t *restrict dst, _Float16 *restrict a, int n) > +{ > + for (int i =3D 0; i < n; i++) > + dst[i] =3D (int64_t) a[i]; > +} > + > +/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" } } *= / > diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc > index c08d0ef951f..c78a750301d 100644 > --- a/gcc/tree-vect-stmts.cc > +++ b/gcc/tree-vect-stmts.cc > @@ -5192,29 +5192,65 @@ vectorizable_conversion (vec_info *vinfo, > break; > } > > - /* For conversions between float and smaller integer types try whe= ther we > - can use intermediate signed integer types to support the > + /* For conversions between float and integer types try whether > + 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)) > + && GET_MODE_SIZE (lhs_mode) !=3D GET_MODE_SIZE (rhs_mode)) this > || (code =3D=3D FIX_TRUNC_EXPR > - && GET_MODE_SIZE (rhs_mode) > GET_MODE_SIZE (lhs_mode) > - && !flag_trapping_math)) > + && (GET_MODE_SIZE (rhs_mode) !=3D GET_MODE_SIZE (lhs_mode) and this check are now common between the FLOAT_EXPR and FIX_TRUNC_EXPR cases > + && !flag_trapping_math))) > { > + bool demotion =3D GET_MODE_SIZE (rhs_mode) > GET_MODE_SIZE (lhs= _mode); > bool float_expr_p =3D code =3D=3D FLOAT_EXPR; > - scalar_mode imode =3D float_expr_p ? rhs_mode : lhs_mode; > - fltsz =3D GET_MODE_SIZE (float_expr_p ? lhs_mode : rhs_mode); > + unsigned short target_size; > + scalar_mode intermediate_mode; > + if (demotion) > + { > + intermediate_mode =3D lhs_mode; > + target_size =3D GET_MODE_SIZE (rhs_mode); > + } > + else > + { > + target_size =3D GET_MODE_SIZE (lhs_mode); > + tree itype > + =3D build_nonstandard_integer_type (GET_MODE_BITSIZE > + (rhs_mode), 0); > + intermediate_mode =3D SCALAR_TYPE_MODE (itype); you should be able to use int_mode_for_size? It might be that, for example _Float128 doesn't have a corresponding integer mode (like on 32bit archs without __int128), so we should check it exists. > + } > code1 =3D float_expr_p ? code : NOP_EXPR; > codecvt1 =3D float_expr_p ? NOP_EXPR : code; > - FOR_EACH_2XWIDER_MODE (rhs_mode_iter, imode) > + opt_scalar_mode mode_iter; > + FOR_EACH_2XWIDER_MODE (mode_iter, intermediate_mode) > { > - imode =3D rhs_mode_iter.require (); > - if (GET_MODE_SIZE (imode) > fltsz) > + intermediate_mode =3D mode_iter.require (); > + > + if (GET_MODE_SIZE (intermediate_mode) > target_size) > break; > > cvt_type > - =3D build_nonstandard_integer_type (GET_MODE_BITSIZE (imo= de), > + =3D build_nonstandard_integer_type (GET_MODE_BITSIZE > + (intermediate_mode), > 0); the 0); now fits on the previous line? Otherwise looks OK to me. Thanks, Richard. > + > + /* Check if the intermediate type can hold OP0's range. > + When converting from float to integer, this is not neces= sary > + because values that do not fit the (smaller) target type= are > + unspecified anyway. */ > + if (demotion && float_expr_p) > + { > + wide_int op_min_value, op_max_value; > + if (!vect_get_range_info (op0, &op_min_value, &op_max_v= alue)) > + goto unsupported; > + > + if (cvt_type =3D=3D NULL_TREE > + || (wi::min_precision (op_max_value, SIGNED) > + > TYPE_PRECISION (cvt_type)) > + || (wi::min_precision (op_min_value, SIGNED) > + > TYPE_PRECISION (cvt_type))) > + goto unsupported; > + } > + > cvt_type =3D get_vectype_for_scalar_type (vinfo, cvt_type, > slp_node); > /* This should only happened for SLP as long as loop vector= izer > -- > 2.41.0 > >