From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) by sourceware.org (Postfix) with ESMTPS id 6871D3858D20 for ; Fri, 5 May 2023 12:37:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6871D3858D20 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-pj1-x1032.google.com with SMTP id 98e67ed59e1d1-24e1d272b09so1317555a91.1 for ; Fri, 05 May 2023 05:37:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; t=1683290259; x=1685882259; 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=HbKsrj6INhrl0vViBNX5kqJYPJGDnmbBSUPBJtE23/M=; b=JjXYSaY84p/IONCL19lck0GATc/QoqPwI55SvN8xUJHKmtLT9viKFLoJkqcrxnnkzD B3wIS1IJoyJZaqLUZtOgVydhJb/qo9oXp9QSdviTehfWVsMnpqzwwTBc8DqtKNO4c/eb cRaZezwtoa2dXPH0ou98B1EzCzw1nX52w8RGiTIv3/8dungrRi0FtFbC/zkaotieIdoS o7o+3L6E03kE/QDcr7RWdmmtyB5tqXY603fAD/rordxWV89eDMF4ML12Wgcbrwuhe5Po YELqPXC77bwZexXfGqsEQDpczuT0VBvRbfyjIt84TG+YCuaqp1TWlomTNLQx5ywVJuOd g1sA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683290259; x=1685882259; 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=HbKsrj6INhrl0vViBNX5kqJYPJGDnmbBSUPBJtE23/M=; b=ea2jQ1ryBJjJXbQFoY8Y2Ec3BHYwEasjhXN9s1OSOexfNO0wfoN6M6izVojWH0aCrX NjpY9jRrKepPQQcr/rLpCiIu9/yDbl8DXM5aqm8QcO+X2aJWGrwYunxH9Vb3HosonNvH VfMrdtn94RJ1t3mgf5fShD/NEPzEVsXNghm4PInTd+p3i6mGZdFrk+RVJ0YmPJXvTEpJ YVlyjtbrpOTGLZ2ohH2JuhiS01GEAlh+LQKJRXVBjD5VChxOxqqasez0ZoQltE31k8rq 2yAmXyJ7E+ZbIIVbZsIHEKjEpG+TT5MNEXl6Va3KyHBfgSlWtIfumqlHPSmvhGitpzSS HpnQ== X-Gm-Message-State: AC+VfDx+0DCfiOGN4rBuuUJB3j2xmwLH/wrEB7wZvl8sUQGrUO2HVd97 ha9UNlFTqBz6WZ0/pLPRp3Bq2MGqvYLHs4OXP3FEpFANI4AkePUL X-Google-Smtp-Source: ACHHUZ6Wv/7ZY6jFLtDVn4I8TaI2gv/PSt+8/PxKyNKt3eKbBHD6gmf38QUGFdsZhShR/lzBJKSphl0jlS5GrKUxUZ8= X-Received: by 2002:a17:90a:9418:b0:246:f710:4f01 with SMTP id r24-20020a17090a941800b00246f7104f01mr1316007pjo.35.1683290259319; Fri, 05 May 2023 05:37:39 -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: From: Kito Cheng Date: Fri, 5 May 2023 20:37:27 +0800 Message-ID: Subject: Re: [PATCH] RISC-V: Allow RVV VMS{Compare}(V1, V1) simplify to VMSET To: "Li, Pan2" Cc: "gcc-patches@gcc.gnu.org" , "juzhe.zhong@rivai.ai" , "Wang, Yanzhang" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.2 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: I will take V1 and commit to trunk after my local test is done :) On Fri, May 5, 2023 at 8:30=E2=80=AFPM Li, Pan2 wrote: > > Hi kito, > > Could you please help to share any suggestion about the PATCH? Comparing = the V1 and V2. > > Pan > > > -----Original Message----- > From: Li, Pan2 > Sent: Wednesday, May 3, 2023 7:18 PM > To: Jeff Law ; Kito Cheng > Cc: gcc-patches@gcc.gnu.org; juzhe.zhong@rivai.ai; Wang, Yanzhang ; Andrew Waterman > Subject: RE: [PATCH] RISC-V: Allow RVV VMS{Compare}(V1, V1) simplify to V= MSET > > Thanks all for comments, will work with kito to make it happen. > > Pan > > -----Original Message----- > From: Jeff Law > Sent: Wednesday, May 3, 2023 12:28 AM > To: Kito Cheng > Cc: Li, Pan2 ; gcc-patches@gcc.gnu.org; juzhe.zhong@ri= vai.ai; Wang, Yanzhang ; Andrew Waterman > Subject: Re: [PATCH] RISC-V: Allow RVV VMS{Compare}(V1, V1) simplify to V= MSET > > > > On 4/29/23 19:40, Kito Cheng wrote: > > 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 = value: > > > > (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))) > Right. My concern is that when we call relational_result it's going to r= eturn -1 (as a vector of bools) which bubbles up through the call > chain. If that doesn't match the actual register state after the > instruction (irrespective of the tail policy), then we have the potential= to generate incorrect code. > > For example, if there's a subsequent instruction that tried to set a vect= or register to -1, it could just copy from the destination of the vmset to = the new target. But if the vmset didn't set all the bits to 1, then the co= de is wrong. > > With all the UNSPECs in place, this may not be a problem in practice. > Unsure. I'm willing to defer to you on this Kito. > > Jeff