From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) by sourceware.org (Postfix) with ESMTPS id CD4FF3858C78 for ; Tue, 23 May 2023 21:07:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CD4FF3858C78 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-x533.google.com with SMTP id 4fb4d7f45d1cf-510d967249aso631040a12.1 for ; Tue, 23 May 2023 14:07:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684876024; x=1687468024; 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=1X8FWOEj1HfZHE6Ibe2CgjwA2e4FquQgMNUUz1BGvM0=; b=Dbh4OK/dcPX2QG0eW72Ilrz6ttMBOexpdcBuJzUvuoZyNvS+nFAUr3EzPe7JHcffgJ hETegv1i2k/T/i1PINKRWLlfVZuANUgplyB9fgZpWQg4sxgSboeqe2TbGrEgr+BzDXt3 KPZIMUAhZRw2tNoA0g/40Q2sFG6RMa6scm0SPkzfcP1QHoxG/4Yxp/cDYWyLoSjMp9oh g7YHgieSjBJ1Fzhbhb+71G5Ck6RrwUmLnbov+L69RHr3nsr9k6ixJ9Fpk6SE07dYKuCI Y+QP7dup+VLv043V6SZxj6ec70Yyp/RrPfj8udWt1t2E7Ipy4PZVpzb6qN8x3fEhMpAD Cy5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684876024; x=1687468024; 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=1X8FWOEj1HfZHE6Ibe2CgjwA2e4FquQgMNUUz1BGvM0=; b=k1zUrirl0LlZV2g1fdROhbaqzLMQbi0fTpQKBhpuNZtVACIcWa0xRQ+cO0C5pmMyBZ KAi8829EwqScuYyz+qpi6L2XBFiEybCZZjdQD6orc9Wvotc204Dd79esG7g3W67fYQO7 mVFuDZGZKZDp8R6Fm0lnBR0sIOvrZQR3ap9hqU6qPuWjDtdDKQb0WkPyKk60P6RsG6ND 6zrviAITGwDwi97BlgtOY3nefE4m2Z6tDWBzeu4pyxfr3Q27ij/3E6F36yoik7DAvUJH 1EZNgLZLuFSQanZjf0Ys4gtaRpyYd/Ltu7AX4zOznDxnqZOP237y/WeMz8RS7lmriWrx 3Tmg== X-Gm-Message-State: AC+VfDyV/ipfHElTC6HH4bYQfhBYZSdr4ugpusB0GD6Y5gtqlLf+P1kl e37tBp+yqiLK09XtmYOlz20= X-Google-Smtp-Source: ACHHUZ7he98EvVmWe2khVVv+cG9tkdgc7h2xS436E55QmEr4WKrWdPJxLhukzuk+o2YreuZ1C3+kug== X-Received: by 2002:aa7:d8d0:0:b0:50b:c4f0:c200 with SMTP id k16-20020aa7d8d0000000b0050bc4f0c200mr268069eds.41.1684876024458; Tue, 23 May 2023 14:07:04 -0700 (PDT) Received: from [192.168.1.24] (ip-046-005-130-086.um12.pools.vodafone-ip.de. [46.5.130.86]) by smtp.gmail.com with ESMTPSA id k3-20020aa7d8c3000000b0050bfc4a9020sm4469140eds.38.2023.05.23.14.07.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 23 May 2023 14:07:04 -0700 (PDT) Message-ID: <29b11c37-930e-11bc-f37b-b51a1c542a80@gmail.com> Date: Tue, 23 May 2023 23:07:02 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Cc: rdapp.gcc@gmail.com, "kito.cheng" , "kito.cheng" , palmer , palmer , Jeff Law , "richard.sandiford" Subject: Re: [PATCH V2] RISC-V: Add RVV comparison autovectorization Content-Language: en-US To: =?UTF-8?B?6ZKf5bGF5ZOy?= , gcc-patches References: <20230523135007.682279-1-juzhe.zhong@rivai.ai> <3C935BB6459CD686+2023052323085803005416@rivai.ai> From: Robin Dapp In-Reply-To: <3C935BB6459CD686+2023052323085803005416@rivai.ai> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NEW_PRODUCTS,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: >>> Don't you want to use your shiny new operand passing style here as >>> with the other expanders? > Hmmmm, I do this just following ARM code style. > You can see I do pass rtx[] for expand_vcond and pass rtx,rtx,rtx for expand_vec_cmp. > Well, I just follow ARM SVE implementation (You can check aarch64-sve.md, we are the same)  :) > If don't like it, could give me more information then I change it for you. It doesn't matter that much in the end. I just wondered that we just introduced a new style of passing operands to the insn_expander and then immediately not use it in the first follow up :) Nit: + e.set_policy (op_num == RVV_CMP_OP ? MASK_UNDISTURBED : MASK_ANY); This looks weird in an emit__cmp_insn. Without a comment it's unclear why anything else but a CMP_OP would ever be used here. The double meaning of the enum (that I wanted to be an instruction type rather than a "number of operands") doesn't help. But well, fixable in the future. We just need to make sure not to accumulate too many of these warts. >From the expander side V3 looks clean now. The integer parts look OK to me but I haven't checked the FP side at all. Regards Robin