From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) by sourceware.org (Postfix) with ESMTPS id C04963858428 for ; Fri, 14 Jul 2023 15:16:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C04963858428 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-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-5216f44d881so139857a12.1 for ; Fri, 14 Jul 2023 08:16:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689347803; x=1691939803; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:cc:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=8wiQ34PBvgWIfMiBdeHSek/lrDXs6yxmk61+wPjwsbo=; b=PshwFQ6G5RfMZH9of/i8W6dUYmKgQWQX/EKyRicRCC5UnojIqM4BcvE4Dw1L9rlHY0 5mRzwEXM7aK/xHl+AMWleBuTzhOzBH/H54FJQGwpZTj1Jf+QQRuFQpQEMxKTz9+DnODx jnOUHCSQmm80mWWz/no19blZt3pyGRmDgUl3PhL/r2q83Oiy7D6gwaALrtJljjTcVRsD ugUJtN8SS+407lYYx4PFQ/bf15W66aRlflNz7QIQva1kUqsF+7S+cMXJ1uToFJeF9HBJ ZPQz5AvSe9j678UBxmZVxIaNclxXQR5q+rLLxlt7rBJL3OIKjR79R+R2FdXEH6uXwoXk Fegw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689347803; x=1691939803; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:cc:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=8wiQ34PBvgWIfMiBdeHSek/lrDXs6yxmk61+wPjwsbo=; b=BBw90pl64MiX1yfueDEAJzxBvJVMQAcvxIadV9HN/v2IEsskC1BzUV0lOTlOJ2/xw8 2UvPAgf503l+P7xlpRxeF0sp0n9oB6hB+R04UdESI7USNiES27ksejBA6Qk4yqbCvWLd y40qm+4VXZ54gl9l+SER1mWCH/qaKBX1PvydABbHhJRkj8BIvJsf3qInkE0LON7Cy/ab gtqH9Vm3fppbKeWMj61JFbSMZRkMJiLMbilcZs0TXrHa6qZccLooz2RRux+FTHDPtkx1 f2cInR4mC1nH7PpsstscgjSRdnM8SC/eTYU/YKKfraLkz0mKLWirH6SR4KVqGlo1lUQJ W7bA== X-Gm-Message-State: ABy/qLYzknegbcUVZInJ3bdFrmtUnUNahWhvmbjyHtr9meXzP+4KP7z9 xk8UJrOs4OQjm4IRgKBQ1aXpQsqxh+u/qw== X-Google-Smtp-Source: APBJJlFEFCH0/BIbxKnThKdVfOPf8Kq3cwLomA3iEdW5PR4Fv+wgppD02OjOXtKuc1vSyAP4sbVQKA== X-Received: by 2002:a17:906:535b:b0:988:f307:aea3 with SMTP id j27-20020a170906535b00b00988f307aea3mr4425257ejo.9.1689347803114; Fri, 14 Jul 2023 08:16:43 -0700 (PDT) Received: from [192.168.1.23] (ip-046-005-130-086.um12.pools.vodafone-ip.de. [46.5.130.86]) by smtp.gmail.com with ESMTPSA id qt25-20020a170906ecf900b00992ab0262c9sm5544526ejb.147.2023.07.14.08.16.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 14 Jul 2023 08:16:42 -0700 (PDT) Message-ID: <632f5e92-f1b7-816f-3f16-9ba09e53c5ab@gmail.com> Date: Fri, 14 Jul 2023 17:16:41 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Cc: rdapp.gcc@gmail.com, gcc-patches Subject: [PATCH v2] vect: Handle demoting FLOAT and promoting FIX_TRUNC. Content-Language: en-US To: Richard Biener References: From: Robin Dapp In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-9.3 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: >>> 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 == 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 == NONE. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/conversions/vec-narrow-int64-float16.c: New test. * gcc.target/riscv/rvv/autovec/conversions/vec-widen-float16-int64.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/conversions/vec-narrow-int64-float16.c create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/conversions/vec-widen-float16-int64.c diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/conversions/vec-narrow-int64-float16.c b/gcc/testsuite/gcc.target/riscv/rvv/autovec/conversions/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-int64-float16.c @@ -0,0 +1,12 @@ +/* { dg-do compile } */ +/* { dg-additional-options "-std=c99 -fno-vect-cost-model -march=rv64gcv_zvfh -mabi=lp64d --param=riscv-autovec-preference=scalable" } */ + +#include + +void convert (_Float16 *restrict dst, int64_t *restrict a, int n) +{ + for (int i = 0; i < n; i++) + dst[i] = (_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-widen-float16-int64.c b/gcc/testsuite/gcc.target/riscv/rvv/autovec/conversions/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-float16-int64.c @@ -0,0 +1,12 @@ +/* { dg-do compile } */ +/* { dg-additional-options "-std=c99 -fno-vect-cost-model -march=rv64gcv_zvfh -mabi=lp64d --param=riscv-autovec-preference=scalable -fno-trapping-math" } */ + +#include + +void convert (int64_t *restrict dst, _Float16 *restrict a, int n) +{ + for (int i = 0; i < n; i++) + dst[i] = (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 whether 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 == FLOAT_EXPR - && GET_MODE_SIZE (lhs_mode) > GET_MODE_SIZE (rhs_mode)) + && GET_MODE_SIZE (lhs_mode) != GET_MODE_SIZE (rhs_mode)) || (code == FIX_TRUNC_EXPR - && GET_MODE_SIZE (rhs_mode) > GET_MODE_SIZE (lhs_mode) - && !flag_trapping_math)) + && (GET_MODE_SIZE (rhs_mode) != GET_MODE_SIZE (lhs_mode) + && !flag_trapping_math))) { + bool demotion = GET_MODE_SIZE (rhs_mode) > GET_MODE_SIZE (lhs_mode); bool float_expr_p = code == FLOAT_EXPR; - scalar_mode imode = float_expr_p ? rhs_mode : lhs_mode; - fltsz = GET_MODE_SIZE (float_expr_p ? lhs_mode : rhs_mode); + unsigned short target_size; + scalar_mode intermediate_mode; + if (demotion) + { + intermediate_mode = lhs_mode; + target_size = GET_MODE_SIZE (rhs_mode); + } + else + { + target_size = GET_MODE_SIZE (lhs_mode); + tree itype + = build_nonstandard_integer_type (GET_MODE_BITSIZE + (rhs_mode), 0); + intermediate_mode = SCALAR_TYPE_MODE (itype); + } code1 = float_expr_p ? code : NOP_EXPR; codecvt1 = 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 = rhs_mode_iter.require (); - if (GET_MODE_SIZE (imode) > fltsz) + intermediate_mode = mode_iter.require (); + + if (GET_MODE_SIZE (intermediate_mode) > target_size) break; cvt_type - = build_nonstandard_integer_type (GET_MODE_BITSIZE (imode), + = build_nonstandard_integer_type (GET_MODE_BITSIZE + (intermediate_mode), 0); + + /* Check if the intermediate type can hold OP0's range. + When converting from float to integer, this is not necessary + 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_value)) + goto unsupported; + + if (cvt_type == 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 = get_vectype_for_scalar_type (vinfo, cvt_type, slp_node); /* This should only happened for SLP as long as loop vectorizer -- 2.41.0