From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) by sourceware.org (Postfix) with ESMTPS id 6AF20385702F for ; Thu, 20 Apr 2023 08:58:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6AF20385702F 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-ej1-x633.google.com with SMTP id dx24so4615476ejb.11 for ; Thu, 20 Apr 2023 01:58:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681981134; x=1684573134; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=f9YAqFs2oYvS2CRllaLdAdaZ1FwPyBuugLV85k8h8BU=; b=mELVmlsv+oxJLRr0f5U1RJ8xSp14Rp9Smyfhtd+999PPuo18Y2fX/lRsp2s5P/37os jxxgUh/JZuMDKV1wdCxxub3hLh2CyAFWgROTzJwXsV2sKEgnXOqR03c8vgElkW/ATYAQ MhUOpfZuH2Mtmo1oHfi1XMvp88um3j4kMLgoOHOsAJaRtkxH9Ni9YasrQHy9byEbo81p 3NtVV0RkDL9BP02e4awKaNiRyMzREFLjZuGZ2dCKqQHUdrePAAEBM9XeBBghG4qv99RL v8c1cPLI54Z/3N98MSdPqS2fWWm7g5mtKPMrIYumMHbhyCrR65jkgSyEj5bYGY20fZ1T aSfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681981134; x=1684573134; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=f9YAqFs2oYvS2CRllaLdAdaZ1FwPyBuugLV85k8h8BU=; b=Avh+Ru+NS7l884nPN0xCSgbiX/IOSVGQkPET9YaCQLODW09qtVpbJMj8ck7EuE5QFA yR2xpVF1PF3RmhBTMc7bVf9LK9q+6zY3eSfaHCKC+2100p+Hi0K/6TKOeb/wcf1j5fgh iI5dbONq9i63o7nT9m8qzE246gtO8XF1HKA1QEKVt+1QZskwZ1iWr8wbB7EMdsCdkDmh 6GEwPyTjiN1nX2qgnn++QsqdWeaE3ULpC7H0d/b/pwM1tSE1k5ZOnyY5YbHJ3IsAkO1w kdM6/GI2M3gQqORU8dtRZ1KAhBCpyWzge7mTS5Qj+MFYI847o6gE4RNz8umXndOwsSGB FvHA== X-Gm-Message-State: AAQBX9cU86Q2r0DUMQp8BZPofeibHW4WGVrLmbhfv5VDqALbYVDGYwpB r4rrXeuR6aKK3w/QfgEJfoc= X-Google-Smtp-Source: AKy350Y6vXV2yeIBBZRC/d0bVZTCdHUmDB3hpwbH33htCq1oXXyk414asL9GYABLatrshZS5OmhyhQ== X-Received: by 2002:a17:906:d79a:b0:8e1:12b6:a8fc with SMTP id pj26-20020a170906d79a00b008e112b6a8fcmr857012ejb.4.1681981134463; Thu, 20 Apr 2023 01:58:54 -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 qp24-20020a170907207800b00882f9130eafsm494618ejb.26.2023.04.20.01.58.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 20 Apr 2023 01:58:54 -0700 (PDT) Message-ID: <97521df8-fdc6-a407-c156-234bdcb34cac@gmail.com> Date: Thu, 20 Apr 2023 10:58:53 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: [PATCH 2/3 V2] RISC-V: Enable basic auto-vectorization for RVV Content-Language: en-US To: Kito Cheng , juzhe.zhong@rivai.ai Cc: gcc-patches@gcc.gnu.org, palmer@dabbelt.com, jeffreyalaw@gmail.com References: <20230419164214.1032017-1-juzhe.zhong@rivai.ai> <20230419164214.1032017-3-juzhe.zhong@rivai.ai> From: Robin Dapp In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE,WEIRD_PORT 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: > $ riscv64-unknown-linux-gnu-gcc > --param=riscv-autovec-preference=fixed-vlmax > gcc/testsuite/gcc.target/riscv/rvv/base/spill-10.c -O2 -march=rv64gcv > -S > ../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/testsuite/gcc.target/riscv/rvv/base/spill-10.c: > In function 'stach_check_alloca_1': > ../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/testsuite/gcc.target/riscv/rvv/base/spill-10.c:41:1: > error: insn does not satisfy its constraints: > 41 | } > | ^ > (insn 37 26 40 2 (set (reg:VNx8QI 120 v24 [orig:158 data ] [158]) > (reg:VNx8QI 10 a0 [ data ])) > "../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/testsuite/gcc.target/riscv/rvv/base/spill-10.c":28:1 > 727 {*movvnx8qi_whole} > (nil)) > during RTL pass: reload > ../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/testsuite/gcc.target/riscv/rvv/base/spill-10.c:41:1: > internal compiler error: in extract_constrain_insn, at recog.cc:2692 For a slightly adjusted testcase void foo0 (int32_t *__restrict f, int32_t *__restrict d, int n) { for (int i = 0; i < n; ++i) { f[i * 2 + 0] = 1; f[i * 2 + 1] = 2; d[i] = 3; } } compiled with -fno-vect-cost-model --param=riscv-autovec-preference=scalable I see an ICE: during GIMPLE pass: vect dump file: foo3.c.172t.vect foo3.c: In function 'foo0': foo3.c:4:1: internal compiler error: in exact_div, at poly-int.h:2232 4 | foo0 (int32_t *__restrict f, int32_t *__restrict d, int n) | ^~~~ 0x7bb237 poly_int<2u, poly_result::is_poly>::type, poly_coeff_pair_traits::is_poly>::type>::result_kind>::type> exact_div<2u, unsigned long, int>(poly_int_pod<2u, unsigned long> const&, int) ../../gcc/poly-int.h:2232 0x7bbf91 poly_int<2u, poly_result::is_poly>::type, poly_coeff_pair_traits::is_poly>::type>::result_kind>::type> exact_div<2u, unsigned long, int>(poly_int_pod<2u, unsigned long> const&, int) ../../gcc/tree.h:3663 0x7bbf91 can_duplicate_and_interleave_p(vec_info*, unsigned int, tree_node*, unsigned int*, tree_node**, tree_node**) ../../gcc/tree-vect-slp.cc:437 [..] With --param=riscv-autovec-preference=fixed-vlmax, however, the output is reasonable. BTW please use --param instead of -param in the description to avoid confusion. Now the patches don't explicitly note that they only work for certain marchs, configurations or so but they certainly shouldn't introduce ICEs for unsupported configurations. Are the "fixed-vlmax" vs "scalable" names based on ARM's SVE? I haven't thought this through but I think I'd prefer "fixed" vs "varying" or more explicitly "fixed vector size" vs "dynamic vector size". Certainly room for discussion here. What about the -mriscv-vector-bits=... (which would be vlen in v-spec parlance) from your "rvv-next" branch? Is this orthogonal to the new parameter here? Are you thinking of introducing this as well? Regards Robin