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
next prev parent 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).