From: Richard Biener <rguenther@suse.de>
To: Richard Sandiford <richard.sandiford@arm.com>
Cc: Prathamesh Kulkarni <prathamesh.kulkarni@linaro.org>,
gcc Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [aarch64] Use dup and zip1 for interleaving elements in initializing vector
Date: Mon, 13 Mar 2023 07:33:01 +0000 (UTC) [thread overview]
Message-ID: <nycvar.YFH.7.77.849.2303130729320.18795@jbgna.fhfr.qr> (raw)
In-Reply-To: <mpt4jqsxyvd.fsf@arm.com>
On Fri, 10 Mar 2023, Richard Sandiford wrote:
> Sorry for the slow reply.
>
> Prathamesh Kulkarni <prathamesh.kulkarni@linaro.org> writes:
> > Unfortunately it regresses code-gen for the following case:
> >
> > svint32_t f(int32x4_t x)
> > {
> > return svdupq_s32 (x[0], x[1], x[2], x[3]);
> > }
> >
> > -O2 code-gen with trunk:
> > f:
> > dup z0.q, z0.q[0]
> > ret
> >
> > -O2 code-gen with patch:
> > f:
> > dup s1, v0.s[1]
> > mov v2.8b, v0.8b
> > ins v1.s[1], v0.s[3]
> > ins v2.s[1], v0.s[2]
> > zip1 v0.4s, v2.4s, v1.4s
> > dup z0.q, z0.q[0]
> > ret
> >
> > IIUC, svdupq_impl::expand uses aarch64_expand_vector_init
> > to initialize the "base 128-bit vector" and then use dupq to replicate it.
> >
> > Without patch, aarch64_expand_vector_init generates fallback code, and then
> > combine optimizes a sequence of vec_merge/vec_select pairs into an assignment:
> >
> > (insn 7 3 8 2 (set (reg:SI 99)
> > (vec_select:SI (reg/v:V4SI 97 [ x ])
> > (parallel [
> > (const_int 1 [0x1])
> > ]))) "bar.c":6:10 2592 {aarch64_get_lanev4si}
> > (nil))
> >
> > (insn 13 9 15 2 (set (reg:V4SI 102)
> > (vec_merge:V4SI (vec_duplicate:V4SI (reg:SI 99))
> > (reg/v:V4SI 97 [ x ])
> > (const_int 2 [0x2]))) "bar.c":6:10 1794 {aarch64_simd_vec_setv4si}
> > (expr_list:REG_DEAD (reg:SI 99)
> > (expr_list:REG_DEAD (reg/v:V4SI 97 [ x ])
> > (nil))))
> >
> > into:
> > Trying 7 -> 13:
> > 7: r99:SI=vec_select(r97:V4SI,parallel)
> > 13: r102:V4SI=vec_merge(vec_duplicate(r99:SI),r97:V4SI,0x2)
> > REG_DEAD r99:SI
> > REG_DEAD r97:V4SI
> > Successfully matched this instruction:
> > (set (reg:V4SI 102)
> > (reg/v:V4SI 97 [ x ]))
> >
> > which eventually results into:
> > (note 2 25 3 2 NOTE_INSN_DELETED)
> > (note 3 2 7 2 NOTE_INSN_FUNCTION_BEG)
> > (note 7 3 8 2 NOTE_INSN_DELETED)
> > (note 8 7 9 2 NOTE_INSN_DELETED)
> > (note 9 8 13 2 NOTE_INSN_DELETED)
> > (note 13 9 15 2 NOTE_INSN_DELETED)
> > (note 15 13 17 2 NOTE_INSN_DELETED)
> > (note 17 15 18 2 NOTE_INSN_DELETED)
> > (note 18 17 22 2 NOTE_INSN_DELETED)
> > (insn 22 18 23 2 (parallel [
> > (set (reg/i:VNx4SI 32 v0)
> > (vec_duplicate:VNx4SI (reg:V4SI 108)))
> > (clobber (scratch:VNx16BI))
> > ]) "bar.c":7:1 5202 {aarch64_vec_duplicate_vqvnx4si_le}
> > (expr_list:REG_DEAD (reg:V4SI 108)
> > (nil)))
> > (insn 23 22 0 2 (use (reg/i:VNx4SI 32 v0)) "bar.c":7:1 -1
> > (nil))
> >
> > I was wondering if we should add the above special case, of assigning
> > target = vec in aarch64_expand_vector_init, if initializer is {
> > vec[0], vec[1], ... } ?
>
> I'm not sure it will be easy to detect that. Won't the inputs to
> aarch64_expand_vector_init just be plain registers? It's not a
> good idea in general to search for definitions of registers
> during expansion.
>
> It would be nice to fix this by lowering svdupq into:
>
> (a) a constructor for a 128-bit vector
> (b) a duplication of the 128-bit vector to fill an SVE vector
>
> But I'm not sure what the best way of doing (b) would be.
> In RTL we can use vec_duplicate, but I don't think gimple
> has an equivalent construct. Maybe Richi has some ideas.
On GIMPLE it would be
_1 = { a, ... }; // (a)
_2 = { _1, ... }; // (b)
but I'm not sure if (b), a VL CTOR of fixed len(?) sub-vectors is
possible? But at least a CTOR of vectors is what we use to
concat vectors.
With the recent relaxing of VEC_PERM inputs it's also possible to
express (b) with a VEC_PERM:
_2 = VEC_PERM <_1, _1, { 0, 1, 2, 3, 0, 1, 2, 3, ... }>
but again I'm not sure if that repeating 0, 1, 2, 3 is expressible
for VL vectors (maybe we'd allow "wrapping" here, I'm not sure).
Richard.
> We're planning to implement the ACLE's Neon-SVE bridge:
> https://github.com/ARM-software/acle/blob/main/main/acle.md#neon-sve-bridge
> and so we'll need (b) to implement the svdup_neonq functions.
>
> Thanks,
> Richard
>
--
Richard Biener <rguenther@suse.de>
SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg,
Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman;
HRB 36809 (AG Nuernberg)
next prev parent reply other threads:[~2023-03-13 7:33 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-29 14:39 Prathamesh Kulkarni
2022-11-29 15:13 ` Andrew Pinski
2022-11-29 17:06 ` Prathamesh Kulkarni
2022-12-05 10:52 ` Richard Sandiford
2022-12-05 11:20 ` Richard Sandiford
2022-12-06 1:31 ` Prathamesh Kulkarni
2022-12-26 4:22 ` Prathamesh Kulkarni
2023-01-12 15:51 ` Richard Sandiford
2023-02-01 9:36 ` Prathamesh Kulkarni
2023-02-01 16:26 ` Richard Sandiford
2023-02-02 14:51 ` Prathamesh Kulkarni
2023-02-02 15:20 ` Richard Sandiford
2023-02-03 1:40 ` Prathamesh Kulkarni
2023-02-03 3:02 ` Prathamesh Kulkarni
2023-02-03 15:17 ` Richard Sandiford
2023-02-04 6:49 ` Prathamesh Kulkarni
2023-02-06 12:13 ` Richard Sandiford
2023-02-11 9:12 ` Prathamesh Kulkarni
2023-03-10 18:08 ` Richard Sandiford
2023-03-13 7:33 ` Richard Biener [this message]
2023-04-03 16:33 ` Prathamesh Kulkarni
2023-04-04 18:05 ` Richard Sandiford
2023-04-06 10:26 ` Prathamesh Kulkarni
2023-04-06 10:34 ` Richard Sandiford
2023-04-06 11:21 ` Prathamesh Kulkarni
2023-04-12 8:59 ` Richard Sandiford
2023-04-21 7:27 ` Prathamesh Kulkarni
2023-04-21 9:17 ` Richard Sandiford
2023-04-21 15:15 ` Prathamesh Kulkarni
2023-04-23 1:53 ` Prathamesh Kulkarni
2023-04-24 9:29 ` Richard Sandiford
2023-05-04 11:47 ` Prathamesh Kulkarni
2023-05-11 19:07 ` Richard Sandiford
2023-05-13 9:10 ` Prathamesh Kulkarni
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=nycvar.YFH.7.77.849.2303130729320.18795@jbgna.fhfr.qr \
--to=rguenther@suse.de \
--cc=gcc-patches@gcc.gnu.org \
--cc=prathamesh.kulkarni@linaro.org \
--cc=richard.sandiford@arm.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).