From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) by sourceware.org (Postfix) with ESMTPS id 89EC83857735 for ; Fri, 5 May 2023 14:52:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 89EC83857735 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-ua1-x934.google.com with SMTP id a1e0cc1a2514c-780b35fc823so170999241.2 for ; Fri, 05 May 2023 07:52:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683298331; x=1685890331; 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=PnB69sAjXPU6KWHFD8FhVQV1bnjc42CrO3+/dhqJm5A=; b=VO+Rl/LThyZAYKWRMROEogKKZrkAM7L3iuXJ0k3PWt4zhZni6wwFqmX7AgxyoxBhfa vTB04MWrNwXJp8+yvaKBD5qRaTQEukjQbtCHG98LJJzSfYd5ltfQZCjCOCFpExASg/9Q gfvka4Gyv/9kRz0877cRc4ss/1IbPZsxml1brA6H/z5OYf/uWR4DbPnUNpSkHWz0mNRX HY4F0G4sz4b8QfenjdaGynk+kGzv4xBm9HsTZBpO0agdQOLk5Hzo0oraLovE9jLDbaOs 8B0JMM88Cj5i8UQx1kXu9A1hb0rS6v9Szi48+GxNksng8wpomRhuIvfqF/npaEULeEsR rCvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683298331; x=1685890331; 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=PnB69sAjXPU6KWHFD8FhVQV1bnjc42CrO3+/dhqJm5A=; b=X6R9WCTbRI8qTTxBmtH7wqcuZq3AKU+822NC3hxs4TG+zQbFw5+2UwUAO3oGOm8T6v pwrQT4aUbIYK2KbH9/9j7zg5IpBRMLzv6tCnTNPzxshLp+DAVPraHRC4V9cWoSJfqOMf hraa9c1JWme/xrw5gJ1RVbQONyQGmnyS7ydcxBgG+3bInFDz+oCG4wKGRT3ZouliKVNL Vj8/YhvWT/NNqyLf7W13TPeLfJi2+vlUL6OlfbuOPf6o9JkTp0k3cgNaCzwXZzM+tjII nzlrcexdMy1oUIyW7y7a80DtYXyom9La97ya71ml9epoQlztgONQy1nd7YsWs5yYhPz7 oJcw== X-Gm-Message-State: AC+VfDyLjO7gBIz2rM66uqlnUEPiKeT2pS80N+NOcGtovXE6qavZeJqq HzSa75HQuuz/ligRl4++mErx7RIe7xzczJoCSRI= X-Google-Smtp-Source: ACHHUZ6OB4hIiMuPpWnx417pqSAWJLxX82iMynyVQzqNQ0+apdhVwDgTD7KyGqYuFz1JWpW2Y7bVQlBrSQRodSbYKLY= X-Received: by 2002:a67:e3bc:0:b0:42f:78d5:d987 with SMTP id j28-20020a67e3bc000000b0042f78d5d987mr664739vsm.1.1683298330725; Fri, 05 May 2023 07:52:10 -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 22:51:59 +0800 Message-ID: Subject: Re: [PATCH] RISC-V: Allow RVV VMS{Compare}(V1, V1) simplify to VMSET To: "Li, Pan2" Cc: Kito Cheng , "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=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,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: pushed v1 to trunk On Fri, May 5, 2023 at 8:46=E2=80=AFPM Li, Pan2 via Gcc-patches wrote: > > Ok, sounds good. Thank you! > > Pan > > -----Original Message----- > From: Kito Cheng > Sent: Friday, May 5, 2023 8:37 PM > To: Li, Pan2 > Cc: gcc-patches@gcc.gnu.org; juzhe.zhong@rivai.ai; Wang, Yanzhang > Subject: Re: [PATCH] RISC-V: Allow RVV VMS{Compare}(V1, V1) simplify to V= MSET > > 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? Comparin= g 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 VMSET > > > > 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@rivai.ai; Wang, Yanzhang ; Andrew > > Waterman > > Subject: Re: [PATCH] RISC-V: Allow RVV VMS{Compare}(V1, V1) simplify > > to VMSET > > > > > > > > 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 undefine= d 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= return -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 potenti= al to generate incorrect code. > > > > For example, if there's a subsequent instruction that tried to set a ve= ctor register to -1, it could just copy from the destination of the vmset t= o the new target. But if the vmset didn't set all the bits to 1, then the = code 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