From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) by sourceware.org (Postfix) with ESMTPS id EA8C63858D28 for ; Sun, 30 Apr 2023 01:40:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EA8C63858D28 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=sifive.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=sifive.com Received: by mail-lj1-x22c.google.com with SMTP id 38308e7fff4ca-2a8c28158e2so11724841fa.0 for ; Sat, 29 Apr 2023 18:40:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; t=1682818812; x=1685410812; 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=poIF1tRywVHip+VVYCeIhOjbmNKYTGK/YAPPkW9zHzw=; b=O+FE14U1UOACIKWEtOeWwnJiqvPr+rbblwNlSnyBGAY7pqtY3lqynL9hr5LLeZjY4o dPGOjWYB+VqPqXwXWe7oTzyQ9aINZKUiEw9pqc9QtHSSX+riXdRbv7w08dth9CNniz5k hElpQh8aCp1I7sxC+m0IB1Lwv9jG+7MNbsMn2uW7+OhgB932p/deNzQ4WTc2qOl74fei 9ey9ulwdBlbPrr1Zs1k8TVqEFvIpgZQ0KLtybvnpuO0SVIH9miwmY+Z2W6J6OPDmTxx0 ivMYRNP+tN4kHCfhPfpqId8ca3RQ+PhkOz3R1emi4KfW2L9gRO3dq1IkTpyISpi55euR 6jeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682818812; x=1685410812; 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=poIF1tRywVHip+VVYCeIhOjbmNKYTGK/YAPPkW9zHzw=; b=WTJmFS3Njp5nkZSlXVZYsgowgGq6x5vwctwWHn4ZosxGAXlk8OLXew9nBPHJ0M0cE/ tq+ZZyRJr4/LgkfRIruCbuclJ3JTGCrXg1sVJB74q6oBBCHlrSkczklP9bAvkNiqC5ml 76FhUFp2TEYQ3kgLXo3Zbkn66kp5DVufehfyLrVyqYgcDmhZU0uX7xa9k3MuaCbyYE4R lYIBBcAGdEsoc3CLfc5Mz5mJWRONAzFuUCCbtrRFL4AjGIRVYUAxXw/EmH2tr4IBwVfu ugNODv9zCJoI4RFH2wayuBpQyfO3L6jdNzVFhmmubHGF75Xe/saZn/vW/q3ZVLKr4CLP /IwQ== X-Gm-Message-State: AC+VfDzq//Y58xKhxkz4gfEYF/om9Y9v/+WjfKBy8LhcrhldDo7r7990 LT11EY4L4RNVk1pLdUgkl5cjzSWPd+WFtPykgVGncA== X-Google-Smtp-Source: ACHHUZ5hm7g0A700o7WomDoGjyz4IyKFl+VQG71ctbGEdMIFJKZU68aJUaiKb3RuKQw+mfPESpndDvjDMaIXe26nriA= X-Received: by 2002:a2e:8017:0:b0:2a6:1681:81e0 with SMTP id j23-20020a2e8017000000b002a6168181e0mr2735359ljg.2.1682818811965; Sat, 29 Apr 2023 18:40:11 -0700 (PDT) MIME-Version: 1.0 References: <20230428152102.1653600-1-pan2.li@intel.com> <2eeda95f-e645-6e73-7bc7-7b829a5bf70b@gmail.com> <72057d65-d5d4-00fc-307a-709ab0a82822@gmail.com> In-Reply-To: <72057d65-d5d4-00fc-307a-709ab0a82822@gmail.com> From: Kito Cheng Date: Sun, 30 Apr 2023 09:40:00 +0800 Message-ID: Subject: Re: [PATCH] RISC-V: Allow RVV VMS{Compare}(V1, V1) simplify to VMSET To: Jeff Law Cc: "Li, Pan2" , "gcc-patches@gcc.gnu.org" , "juzhe.zhong@rivai.ai" , "Wang, Yanzhang" , Andrew Waterman Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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: Hi Jeff: The RTL pattern already models tail element and vector length well, so I don't feel the first version of Pan's patch has any problem? Input RTL pattern: #(insn 10 7 12 2 (set (reg:VNx2BI 134 [ _1 ]) # (if_then_else:VNx2BI (unspec:VNx2BI [ # (const_vector:VNx2BI repeat [ # (const_int 1 [0x1]) # ]) # all-1 mask # (reg:DI 143) # AVL reg, or vector length # (const_int 2 [0x2]) # mask policy # (const_int 0 [0]) # avl type # (reg:SI 66 vl) # (reg:SI 67 vtype) # ] UNSPEC_VPREDICATE) # (geu:VNx2BI (reg/v:VNx2QI 137 [ v1 ]) # (reg/v:VNx2QI 137 [ v1 ])) # (unspec:VNx2BI [ # (reg:SI 0 zero) # ] UNSPEC_VUNDEF))) # maskoff and tail operand # (expr_list:REG_DEAD (reg:DI 143) # (expr_list:REG_DEAD (reg/v:VNx2QI 137 [ v1 ]) # (nil)))) And the split pattern, only did on tail/maskoff element with undefined valu= e: (define_split [(set (match_operand:VB 0 "register_operand") (if_then_else:VB (unspec:VB [(match_operand:VB 1 "vector_all_trues_mask_operand") (match_operand 4 "vector_length_operand") (match_operand 5 "const_int_operand") (match_operand 6 "const_int_operand") (reg:SI VL_REGNUM) (reg:SI VTYPE_REGNUM)] UNSPEC_VPREDICATE) (match_operand:VB 3 "vector_move_operand") (match_operand:VB 2 "vector_undef_operand")))] # maskoff and tail operand, only match undef value Then it turns into vmset, and also discard mask policy operand (since maskoff is undef means don't care IMO): (insn 10 7 12 2 (set (reg:VNx2BI 134 [ _1 ]) (if_then_else:VNx2BI (unspec:VNx2BI [ (const_vector:VNx2BI repeat [ (const_int 1 [0x1]) ]) # all-1 mask (reg:DI 143) # AVL reg, or vector length (const_int 2 [0x2]) # mask policy (reg:SI 66 vl) (reg:SI 67 vtype) ] UNSPEC_VPREDICATE) (const_vector:VNx2BI repeat [ (const_int 1 [0x1]) ]) # all-1 (unspec:VNx2BI [ (reg:SI 0 zero) ] UNSPEC_VUNDEF))) # still vundef (expr_list:REG_DEAD (reg:DI 143) (nil))) On Sat, Apr 29, 2023 at 11:05=E2=80=AFPM Jeff Law w= rote: > > > > On 4/28/23 20:55, Li, Pan2 wrote: > > Thanks Jeff for comments. > > > > It makes sense to me. For the EQ operator we should have CONSTM1. > That's not the way I interpret the RVV documentation. Of course it's > not terribly clear. I guess one could do some experiments with qemu > or try to dig into the sail code and figure out the intent from those. > > > > Does this mean s390 parts has similar issue here? Then for instructions > like VMSEQ, we need to adjust the simplify_rtx up to a point. > You'd have to refer to the s390 instruction set reference to understand > precisely how the vector compares work. > > But as it stands this really isn't a simplify-rtx question, but a > question of the semantics of risc-v. What happens with the high bits > in the destination mask register is critical -- and if risc-v doesn't > set them to all ones in this case, then that would mean that defining > that macro is simply wrong for risc-v. > > jeff