From: Thomas Schwinge <thomas@codesourcery.com>
To: <gcc-patches@gcc.gnu.org>,
Roger Sayle <roger@nextmovesoftware.com>,
"Tom de Vries" <tdevries@suse.de>
Subject: [WIP] nvptx: Also allow immediate input operand to 'bitrev<mode>2'
Date: Mon, 4 Sep 2023 18:24:42 +0200 [thread overview]
Message-ID: <87bkehx5x1.fsf@euler.schwinge.homeip.net> (raw)
[-- Attachment #1: Type: text/plain, Size: 3279 bytes --]
Hi!
I'm working towards reviewing some (of Roger's) GCC/nvptx patches, and
therefore learning some more GCC/nvptx, and generally RTL etc., and the
conventions around it. Please bear with me asking "obvious" questions.
For the PTX bit reverse instruction, GCC/nvptx currently ("forever")
defines:
(define_insn "bitrev<mode>2"
[(set (match_operand:SDIM 0 "nvptx_register_operand" "=R")
(unspec:SDIM [(match_operand:SDIM 1 "nvptx_register_operand" "R")]
UNSPEC_BITREV))]
""
"%.\\tbrev.b%T0\\t%0, %1;")
..., with:
(define_predicate "nvptx_register_operand"
(match_code "reg")
{
return register_operand (op, mode);
})
(define_constraint "R"
"A pseudo register."
(match_code "reg"))
That is, only a register input operand is permitted, not an immediate.
However, I don't see such a restriction in the manual,
<https://docs.nvidia.com/cuda/parallel-thread-execution/#integer-arithmetic-instructions-brev>.
If I change that 'define_insn':
- (unspec:SDIM [(match_operand:SDIM 1 "nvptx_register_operand" "R")]
+ (unspec:SDIM [(match_operand:SDIM 1 "nvptx_nonmemory_operand" "Ri")]
..., with (existing):
(define_predicate "nvptx_nonmemory_operand"
(match_code "reg,const_int,const_double")
{
return (REG_P (op) ? register_operand (op, mode)
: immediate_operand (op, mode));
})
..., then a simple code:
return __builtin_nvptx_brev(0xe6a2c480) != 0x01234567;
... for '-O1' subsequently changes:
[...]
.reg .u32 %r22;
-.reg .u32 %r25;
.reg .pred %r29;
-mov.u32 %r25,-425540480;
-brev.b32 %r22,%r25;
+brev.b32 %r22,-425540480;
setp.ne.u32 %r29,%r22,19088743;
[...]
(I understand that, in the end, that's probably equivalent, assuming that
the later PTX -> SASS compiler does the same optimization, but I find it
easier to read: one less '.reg' to keep track of textually/mentally.)
Does that make sense to you, too? I'd then extend my attached
"[WIP] nvptx: Also allow immediate input operand to 'bitrev<mode>2'" with
a test case.
(Similarly then, a number of other GCC/nvptx 'define_insn's to be
reviewed/revised, later on.)
Relatedly, I see that a lot of GCC/nvptx' two input operands instructions
('add<mode>3', etc.) similarly do allow for their second input operand to
be an immediate in addition to a register. I suppose that only allowing
for the second input operand to be an immediate is sufficient/desirable:
reduces load on the matching; we shouldn't ever end up with 'IMM + IMM',
for example: should've optimized that before. As I learn from
<https://gcc.gnu.org/onlinedocs/gccint/Insn-Canonicalizations.html>,
"for commutative [...] operators, a constant is always made the second
operand". (Confirmed to ICE if swapping that around for 'add<mode>3';
so, that's all as expected.)
Grüße
Thomas
-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-WIP-nvptx-Also-allow-immediate-input-operand-to-bitr.patch --]
[-- Type: text/x-diff, Size: 825 bytes --]
From 4a5138eb61a026ad6bc5470a648ebc596af1b1ed Mon Sep 17 00:00:00 2001
From: Thomas Schwinge <thomas@codesourcery.com>
Date: Mon, 4 Sep 2023 16:48:53 +0200
Subject: [PATCH] [WIP] nvptx: Also allow immediate input operand to
'bitrev<mode>2'
---
gcc/config/nvptx/nvptx.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/config/nvptx/nvptx.md b/gcc/config/nvptx/nvptx.md
index 1bb93045403..e1c822f2ea8 100644
--- a/gcc/config/nvptx/nvptx.md
+++ b/gcc/config/nvptx/nvptx.md
@@ -636,7 +636,7 @@
(define_insn "bitrev<mode>2"
[(set (match_operand:SDIM 0 "nvptx_register_operand" "=R")
- (unspec:SDIM [(match_operand:SDIM 1 "nvptx_register_operand" "R")]
+ (unspec:SDIM [(match_operand:SDIM 1 "nvptx_nonmemory_operand" "Ri")]
UNSPEC_BITREV))]
""
"%.\\tbrev.b%T0\\t%0, %1;")
--
2.34.1
reply other threads:[~2023-09-04 16:24 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=87bkehx5x1.fsf@euler.schwinge.homeip.net \
--to=thomas@codesourcery.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=roger@nextmovesoftware.com \
--cc=tdevries@suse.de \
/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).