public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Li, Pan2" <pan2.li@intel.com>
To: Kito Cheng <kito.cheng@sifive.com>
Cc: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
	"juzhe.zhong@rivai.ai" <juzhe.zhong@rivai.ai>,
	"Wang, Yanzhang" <yanzhang.wang@intel.com>
Subject: RE: [PATCH] RISC-V: Allow RVV VMS{Compare}(V1, V1) simplify to VMSET
Date: Fri, 5 May 2023 12:30:42 +0000	[thread overview]
Message-ID: <MW5PR11MB590819BE2FC4678CAAE6C977A9729@MW5PR11MB5908.namprd11.prod.outlook.com> (raw)
In-Reply-To: <MW5PR11MB590889CDB7BEF60E18BBD54BA96C9@MW5PR11MB5908.namprd11.prod.outlook.com>

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 <jeffreyalaw@gmail.com>; Kito Cheng <kito.cheng@sifive.com>
Cc: gcc-patches@gcc.gnu.org; juzhe.zhong@rivai.ai; Wang, Yanzhang <yanzhang.wang@intel.com>; Andrew Waterman <andrew@sifive.com>
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 <jeffreyalaw@gmail.com> 
Sent: Wednesday, May 3, 2023 12:28 AM
To: Kito Cheng <kito.cheng@sifive.com>
Cc: Li, Pan2 <pan2.li@intel.com>; gcc-patches@gcc.gnu.org; juzhe.zhong@rivai.ai; Wang, Yanzhang <yanzhang.wang@intel.com>; Andrew Waterman <andrew@sifive.com>
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 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 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 potential to generate incorrect code.

For example, if there's a subsequent instruction that tried to set a vector 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 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

  reply	other threads:[~2023-05-05 12:30 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-28 15:21 pan2.li
2023-04-28 21:47 ` Jeff Law
2023-04-29  2:55   ` Li, Pan2
2023-04-29 13:35     ` Li, Pan2
2023-04-29 15:05     ` Jeff Law
2023-04-29 17:21       ` Andrew Waterman
2023-04-29 17:28         ` Palmer Dabbelt
2023-04-29 17:46           ` Jeff Law
2023-04-29 17:48             ` Palmer Dabbelt
2023-04-29 17:52               ` Jeff Law
2023-04-29 18:15                 ` Palmer Dabbelt
2023-04-29 17:49         ` Jeff Law
2023-04-30  1:40       ` Kito Cheng
2023-04-30 14:21         ` Li, Pan2
2023-05-02 16:28         ` Jeff Law
2023-05-03 11:17           ` Li, Pan2
2023-05-05 12:30             ` Li, Pan2 [this message]
2023-05-05 12:37               ` Kito Cheng
2023-05-05 12:45                 ` Li, Pan2
2023-05-05 14:51                   ` Kito Cheng
2023-04-29 13:32 ` [PATCH v2] " pan2.li

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=MW5PR11MB590819BE2FC4678CAAE6C977A9729@MW5PR11MB5908.namprd11.prod.outlook.com \
    --to=pan2.li@intel.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=juzhe.zhong@rivai.ai \
    --cc=kito.cheng@sifive.com \
    --cc=yanzhang.wang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).