public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: 钟居哲 <juzhe.zhong@rivai.ai>
To: rdapp.gcc <rdapp.gcc@gmail.com>,  gcc-patches <gcc-patches@gcc.gnu.org>
Cc: rdapp.gcc <rdapp.gcc@gmail.com>,
	 kito.cheng <kito.cheng@gmail.com>,
	 kito.cheng <kito.cheng@sifive.com>,  palmer <palmer@dabbelt.com>,
	 palmer <palmer@rivosinc.com>,
	 "Jeff Law" <jeffreyalaw@gmail.com>,  pan2.li <pan2.li@intel.com>
Subject: Re: Re: [PATCH] RISC-V: Add RVV vwmacc/vwmaccu/vwmaccsu combine lowering optmization
Date: Tue, 6 Jun 2023 19:35:27 +0800	[thread overview]
Message-ID: <8D5CFAAB047A3662+20230606193526718263173@rivai.ai> (raw)
In-Reply-To: <40b761ad-1267-34b4-e571-ce5e36cebcc9@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4136 bytes --]

Hi, Robin.

>> Here and in the following similar cases you could just use operands
>>instead of creating a new rtx array.
Ok. Thanks for catching this.


>> Similar example as before would be nice or just "this helps combine
>> match ...".   Apart from that I just wondered where/how these unpredicated
>> patterns are being generated at all?  Is this for VLA?
These enhance patterns are generated in complicate combining situations.

>> I had similar patterns locally but just as splitters and not insns.  Didn't
>> make it any less ugly though.  We might be needing several of such patterns
>> still.

Splitters can not work in complicate case, you could try my testcase.
I am 100% it should be define_insn_and_split.

> +;; Combine signe_extend + zero_extend + fma ===> widen fma (su).
Ok.

Will send V2 soon.
Thanks.


juzhe.zhong@rivai.ai
 
From: Robin Dapp
Date: 2023-06-06 19:16
To: juzhe.zhong; gcc-patches
CC: rdapp.gcc; kito.cheng; kito.cheng; palmer; palmer; jeffreyalaw; pan2.li
Subject: Re: [PATCH] RISC-V: Add RVV vwmacc/vwmaccu/vwmaccsu combine lowering optmization
Hi Juzhe,
 
just one/two really minor nits.
 
> +    rtx ops[] = {operands[0], operands[1], operands[2], operands[3]};
> +    riscv_vector::emit_vlmax_ternary_insn (code_for_pred_widen_mul_plus (<CODE>, <MODE>mode),
> +    riscv_vector::RVV_WIDEN_TERNOP, ops);
 
Here and in the following similar cases you could just use operands
instead of creating a new rtx array.
 
> +;; Enhance the combine optimizations.
 
Similar example as before would be nice or just "this helps combine
match ...".   Apart from that I just wondered where/how these unpredicated
patterns are being generated at all?  Is this for VLA?
 
> +;; Combine ext + ext + mult + plus ===> widen fma.
> +;; We have some special cases generated by LoopVectorizer:
> +;;   vect__8.18_46 = (vector([8,8]) signed short) vect__7.17_47;
> +;;   vect__11.22_41 = (vector([8,8]) signed short) vect__10.21_42;
> +;;   vect__12.23_40 = vect__11.22_41 * vect__8.18_46;
> +;;   vect__14.25_38 = vect__13.24_39 + vect__5.14_51;
> +;; This situation doesn't generate FMA IR.
> +(define_insn_and_split "*double_<optab>mult_plus<mode>"
> +  [(set (match_operand:VWEXTI 0 "register_operand")
> + (if_then_else:VWEXTI
> +   (unspec:<VM>
> +     [(match_operand:<VM> 1 "vector_mask_operand")
> +      (match_operand 6 "vector_length_operand")
> +      (match_operand 7 "const_int_operand")
> +      (match_operand 8 "const_int_operand")
> +      (match_operand 9 "const_int_operand")
> +      (reg:SI VL_REGNUM)
> +      (reg:SI VTYPE_REGNUM)] UNSPEC_VPREDICATE)
> +          (plus:VWEXTI
> +     (if_then_else:VWEXTI
> +       (unspec:<VM>
> +         [(match_dup 1)
> +          (match_dup 6)
> +          (match_dup 7)
> +          (match_dup 8)
> +          (match_dup 9)
> +          (reg:SI VL_REGNUM)
> +          (reg:SI VTYPE_REGNUM)] UNSPEC_VPREDICATE)
> +       (mult:VWEXTI
> +         (any_extend:VWEXTI
> +           (match_operand:<V_DOUBLE_TRUNC> 4 "register_operand"))
> +         (any_extend:VWEXTI
> +           (match_operand:<V_DOUBLE_TRUNC> 5 "register_operand")))
> +              (match_operand:VWEXTI 2 "vector_undef_operand"))
> +     (match_operand:VWEXTI 3 "register_operand"))
> +          (match_dup 2)))]
> +  "TARGET_VECTOR && can_create_pseudo_p ()"
> +  "#"
> +  "&& 1"
> +  [(const_int 0)]
> +  {
> +    emit_insn (gen_pred_widen_mul_plus (<CODE>, <MODE>mode, operands[0],
> + operands[1], operands[3], operands[4],
> + operands[5], operands[6], operands[7],
> + operands[8], operands[9]));
 
I had similar patterns locally but just as splitters and not insns.  Didn't
make it any less ugly though.  We might be needing several of such patterns
still.
 
Can't help thinking about tweaking combine at some point in the (distant)
future to at least provide it with some sense of VLA structure.  It could
query the backend for unspec equality and then combine "normally".
 
> +;; Combine signe_extend + zero_extend + fma ===> widen fma (su).
 
-e
 
Regards
Robin
 

  reply	other threads:[~2023-06-06 11:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-06  9:58 juzhe.zhong
2023-06-06 11:16 ` Robin Dapp
2023-06-06 11:35   ` 钟居哲 [this message]
2023-06-06 11:42     ` Robin Dapp
2023-06-06 11:46       ` 钟居哲
2023-06-06 11:58 ` Robin Dapp
2023-06-06 12:05   ` 钟居哲

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=8D5CFAAB047A3662+20230606193526718263173@rivai.ai \
    --to=juzhe.zhong@rivai.ai \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jeffreyalaw@gmail.com \
    --cc=kito.cheng@gmail.com \
    --cc=kito.cheng@sifive.com \
    --cc=palmer@dabbelt.com \
    --cc=palmer@rivosinc.com \
    --cc=pan2.li@intel.com \
    --cc=rdapp.gcc@gmail.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).