From: Richard Sandiford <richard.sandiford@arm.com>
To: Prathamesh Kulkarni <prathamesh.kulkarni@linaro.org>
Cc: gcc Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [aarch64] Code-gen for vector initialization involving constants
Date: Mon, 15 May 2023 19:59:04 +0100 [thread overview]
Message-ID: <mpth6sd5slj.fsf@arm.com> (raw)
In-Reply-To: <CAAgBjMm9__ZPxuNvtaiwSFaS35kWqj2StsQY6atYnUPMzUYYsw@mail.gmail.com> (Prathamesh Kulkarni's message of "Mon, 15 May 2023 19:39:14 +0530")
Prathamesh Kulkarni <prathamesh.kulkarni@linaro.org> writes:
> Hi Richard,
> After committing the interleave+zip1 patch for vector initialization,
> it seems to regress the s32 case for this patch:
>
> int32x4_t f_s32(int32_t x)
> {
> return (int32x4_t) { x, x, x, 1 };
> }
>
> code-gen:
> f_s32:
> movi v30.2s, 0x1
> fmov s31, w0
> dup v0.2s, v31.s[0]
> ins v30.s[0], v31.s[0]
> zip1 v0.4s, v0.4s, v30.4s
> ret
>
> instead of expected code-gen:
> f_s32:
> movi v31.2s, 0x1
> dup v0.4s, w0
> ins v0.s[3], v31.s[0]
> ret
>
> Cost for fallback sequence: 16
> Cost for interleave and zip sequence: 12
>
> For the above case, the cost for interleave+zip1 sequence is computed as:
> halves[0]:
> (set (reg:V2SI 96)
> (vec_duplicate:V2SI (reg/v:SI 93 [ x ])))
> cost = 8
>
> halves[1]:
> (set (reg:V2SI 97)
> (const_vector:V2SI [
> (const_int 1 [0x1]) repeated x2
> ]))
> (set (reg:V2SI 97)
> (vec_merge:V2SI (vec_duplicate:V2SI (reg/v:SI 93 [ x ]))
> (reg:V2SI 97)
> (const_int 1 [0x1])))
> cost = 8
>
> followed by:
> (set (reg:V4SI 95)
> (unspec:V4SI [
> (subreg:V4SI (reg:V2SI 96) 0)
> (subreg:V4SI (reg:V2SI 97) 0)
> ] UNSPEC_ZIP1))
> cost = 4
>
> So the total cost becomes
> max(costs[0], costs[1]) + zip1_insn_cost
> = max(8, 8) + 4
> = 12
>
> While the fallback rtl sequence is:
> (set (reg:V4SI 95)
> (vec_duplicate:V4SI (reg/v:SI 93 [ x ])))
> cost = 8
> (set (reg:SI 98)
> (const_int 1 [0x1]))
> cost = 4
> (set (reg:V4SI 95)
> (vec_merge:V4SI (vec_duplicate:V4SI (reg:SI 98))
> (reg:V4SI 95)
> (const_int 8 [0x8])))
> cost = 4
>
> So total cost = 8 + 4 + 4 = 16, and we choose the interleave+zip1 sequence.
>
> I think the issue is probably that for the interleave+zip1 sequence we take
> max(costs[0], costs[1]) to reflect that both halves are interleaved,
> but for the fallback seq we use seq_cost, which assumes serial execution
> of insns in the sequence.
> For above fallback sequence,
> set (reg:V4SI 95)
> (vec_duplicate:V4SI (reg/v:SI 93 [ x ])))
> and
> (set (reg:SI 98)
> (const_int 1 [0x1]))
> could be executed in parallel, which would make it's cost max(8, 4) + 4 = 12.
Agreed.
A good-enough substitute for this might be to ignore scalar moves
(for both alternatives) when costing for speed.
> I was wondering if we should we make cost for interleave+zip1 sequence
> more conservative
> by not taking max, but summing up costs[0] + costs[1] even for speed ?
> For this case,
> that would be 8 + 8 + 4 = 20.
>
> It generates the fallback sequence for other cases (s8, s16, s64) from
> the test-case.
What does it do for the tests in the interleave+zip1 patch? If it doesn't
make a difference there then it sounds like we don't have enough tests. :)
Summing is only conservative if the fallback sequence is somehow "safer".
But I don't think it is. Building an N-element vector from N scalars
can be done using N instructions in the fallback case and N+1 instructions
in the interleave+zip1 case. But the interleave+zip1 case is still
better (speedwise) for N==16.
Thanks,
Richard
next prev parent reply other threads:[~2023-05-15 18:59 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-03 7:16 Prathamesh Kulkarni
2023-02-13 6:28 ` Prathamesh Kulkarni
2023-04-03 18:12 ` Prathamesh Kulkarni
2023-04-25 10:59 ` Richard Sandiford
2023-05-02 5:41 ` Prathamesh Kulkarni
2023-05-02 9:25 ` Richard Sandiford
2023-05-02 10:22 ` Prathamesh Kulkarni
2023-05-02 12:02 ` Richard Sandiford
2023-05-02 12:38 ` Prathamesh Kulkarni
2023-05-02 12:52 ` Richard Sandiford
2023-05-03 11:28 ` Prathamesh Kulkarni
2023-05-11 19:15 ` Richard Sandiford
2023-05-15 14:09 ` Prathamesh Kulkarni
2023-05-15 18:59 ` Richard Sandiford [this message]
2023-05-17 15:23 ` Prathamesh Kulkarni
2023-05-18 8:07 ` Richard Sandiford
2023-05-18 14:41 ` Prathamesh Kulkarni
2023-05-18 16:34 ` Richard Sandiford
2023-05-19 10:56 ` Prathamesh Kulkarni
2023-05-22 8:48 ` Richard Sandiford
2023-05-24 9:29 ` Prathamesh Kulkarni
2023-05-24 10:10 ` Richard Sandiford
2023-05-24 19:13 ` Prathamesh Kulkarni
2023-05-24 19:58 ` Richard Sandiford
2023-05-25 6:47 ` Prathamesh Kulkarni
2023-05-25 7:34 ` Richard Sandiford
2023-05-25 9:56 ` Prathamesh Kulkarni
2023-05-26 3:04 ` Prathamesh Kulkarni
2023-05-30 18:53 ` Richard Sandiford
2023-06-12 17:52 ` Prathamesh Kulkarni
2023-05-24 19:50 ` 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=mpth6sd5slj.fsf@arm.com \
--to=richard.sandiford@arm.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=prathamesh.kulkarni@linaro.org \
/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).