public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Law <jeffreyalaw@gmail.com>
To: Palmer Dabbelt <palmer@dabbelt.com>, Robin Dapp <rdapp.gcc@gmail.com>
Cc: gcc-patches@gcc.gnu.org, Kito Cheng <kito.cheng@gmail.com>,
	juzhe.zhong@rivai.ai
Subject: Re: [PATCH] RISC-V: Add min/max patterns for ifcvt.
Date: Mon, 3 Jun 2024 12:50:54 -0600	[thread overview]
Message-ID: <3c713e49-51f9-45e6-a94d-02cda11e7f52@gmail.com> (raw)
In-Reply-To: <mhng-dd65531c-ba6f-4774-b45f-4c0df3b408b5@palmer-ri-x1c9>



On 6/3/24 11:03 AM, Palmer Dabbelt wrote:

>>
>> +;; Provide a minmax pattern for ifcvt to match.
>> +(define_insn "*<bitmanip_minmax_cmp_insn>_cmp_<mode>3"
>> +  [(set (match_operand:X 0 "register_operand" "=r")
>> +    (if_then_else:X
>> +        (bitmanip_minmax_cmp_op
>> +        (match_operand:X 1 "register_operand" "r")
>> +        (match_operand:X 2 "register_operand" "r"))
>> +        (match_dup 1)
>> +        (match_dup 2)))]
>> +  "TARGET_ZBB"
>> +  "<bitmanip_minmax_cmp_insn>\t%0,%1,%z2"
>> +  [(set_attr "type" "<bitmanip_minmax_cmp_insn>")])
> 
> This is a bit different than how we're handling the other min/max type 
> attributes
> 
>     (define_insn "*<bitmanip_optab><mode>3"
>       [(set (match_operand:X 0 "register_operand" "=r")
>             (bitmanip_minmax:X (match_operand:X 1 "register_operand" "r")
>                    (match_operand:X 2 "reg_or_0_operand" "rJ")))]
>       "TARGET_ZBB"
>       "<bitmanip_insn>\t%0,%1,%z2"
>       [(set_attr "type" "<bitmanip_insn>")])
> 
> but it looks like it ends up with the same types after all the iterators 
> (there's some "max vs smax" and "smax vs maxs" juggling, but IIUC it 
> ends up in the same place).  I think it'd be clunkier to try and use all 
> the same iterators, though, so
> 
> Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com>
> 
> [I was wondering if we need the reversed, Jeff on the call says we 
> don't.  I couldn't figure out how to write a test for it.]
Right.  I had managed to convince myself that we didn't need the 
reversed case.  I'm less sure now than I was earlier, but I'm also 
confident that if the need arises we can trivially handle it.  At some 
point there's canonicalization of the condition and that's almost 
certainly what's making it hard to synthesize a testcase for the 
reversed pattern.

The other thing I pondered was whether or not we should support SImode 
min/max on rv64.  It was critical for simplifying that abs2 routine in 
x264, but I couldn't convince myself it was needed here.  So I just set 
it aside and didn't mention it.

jeff

  reply	other threads:[~2024-06-03 18:51 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-31 15:07 Robin Dapp
2024-06-01  3:57 ` Jeff Law
2024-06-03 17:03 ` Palmer Dabbelt
2024-06-03 18:50   ` Jeff Law [this message]
2024-06-03 19:29     ` Palmer Dabbelt

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=3c713e49-51f9-45e6-a94d-02cda11e7f52@gmail.com \
    --to=jeffreyalaw@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=juzhe.zhong@rivai.ai \
    --cc=kito.cheng@gmail.com \
    --cc=palmer@dabbelt.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).