From: Richard Sandiford <richard.sandiford@arm.com>
To: "Andre Vieira \(lists\)" <andre.simoesdiasvieira@arm.com>
Cc: "gcc-patches\@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
Kyrylo Tkachov <Kyrylo.Tkachov@arm.com>
Subject: Re: [aarch64] Add Demeter tuning structs
Date: Wed, 16 Mar 2022 16:28:06 +0000 [thread overview]
Message-ID: <mpta6dp9815.fsf@arm.com> (raw)
In-Reply-To: <c6b238fc-280e-59b6-1eec-b7aba745127a@arm.com> (Andre Vieira's message of "Wed, 16 Mar 2022 14:49:30 +0000")
"Andre Vieira (lists)" <andre.simoesdiasvieira@arm.com> writes:
> Hi,
>
> This patch adds tuning structs for -mcpu/-mtune=demeter.
>
>
> 2022-03-16 Tamar Christina <tamar.christina@arm.com>
> Andre Vieira <andre.simoesdiasvieira@arm.com>
>
> * config/aarch64/aarch64.cc (demeter_addrcost_table,
> demeter_regmove_cost,
> demeter_advsimd_vector_cost, demeter_sve_vector_cost,
> demeter_scalar_issue_info,
> demeter_advsimd_issue_info, demeter_sve_issue_info,
> demeter_vec_issue_info,
> demeter_vector_cost, demeter_tunings): New tuning structs.
> (aarch64_ve_op_count::rename_cycles_per_iter): Enable for
> demeter tuning.
> * config/aarch64/aarch64-cores.def: Add entry for demeter.
> * config/aarch64/aarch64-tune.md (tune): Add demeter to list.
>
> diff --git a/gcc/config/aarch64/aarch64-cores.def b/gcc/config/aarch64/aarch64-cores.def
> index eda3a4eb6028d97d50295773c87119d9fa0c41bf..9e6ca84bd4b277ccf2c1809c419703a23075f315 100644
> --- a/gcc/config/aarch64/aarch64-cores.def
> +++ b/gcc/config/aarch64/aarch64-cores.def
> @@ -172,4 +172,6 @@ AARCH64_CORE("cortex-a710", cortexa710, cortexa57, 9A, AARCH64_FL_FOR_ARCH9 |
>
> AARCH64_CORE("cortex-x2", cortexx2, cortexa57, 9A, AARCH64_FL_FOR_ARCH9 | AARCH64_FL_SVE2_BITPERM | AARCH64_FL_MEMTAG | AARCH64_FL_I8MM | AARCH64_FL_BF16, neoversen2, 0x41, 0xd48, -1)
>
> +AARCH64_CORE("demeter", demeter, cortexa57, 9A, AARCH64_FL_FOR_ARCH9 | AARCH64_FL_I8MM | AARCH64_FL_BF16 | AARCH64_FL_SVE2_BITPERM | AARCH64_FL_RNG | AARCH64_FL_MEMTAG | AARCH64_FL_PROFILE, demeter, 0x41, 0xd4f, -1)
> +
> #undef AARCH64_CORE
> diff --git a/gcc/config/aarch64/aarch64-tune.md b/gcc/config/aarch64/aarch64-tune.md
> index 3eed700c063c2abf36cd648b22f713e887255f96..dda5dbdda75c1383004f5dac3f249909f7f23589 100644
> --- a/gcc/config/aarch64/aarch64-tune.md
> +++ b/gcc/config/aarch64/aarch64-tune.md
> @@ -1,5 +1,5 @@
> ;; -*- buffer-read-only: t -*-
> ;; Generated automatically by gentune.sh from aarch64-cores.def
> (define_attr "tune"
> - "cortexa34,cortexa35,cortexa53,cortexa57,cortexa72,cortexa73,thunderx,thunderxt88p1,thunderxt88,octeontx,octeontxt81,octeontxt83,thunderxt81,thunderxt83,ampere1,emag,xgene1,falkor,qdf24xx,exynosm1,phecda,thunderx2t99p1,vulcan,thunderx2t99,cortexa55,cortexa75,cortexa76,cortexa76ae,cortexa77,cortexa78,cortexa78ae,cortexa78c,cortexa65,cortexa65ae,cortexx1,ares,neoversen1,neoversee1,octeontx2,octeontx2t98,octeontx2t96,octeontx2t93,octeontx2f95,octeontx2f95n,octeontx2f95mm,a64fx,tsv110,thunderx3t110,zeus,neoversev1,neoverse512tvb,saphira,neoversen2,cortexa57cortexa53,cortexa72cortexa53,cortexa73cortexa35,cortexa73cortexa53,cortexa75cortexa55,cortexa76cortexa55,cortexr82,cortexa510,cortexa710,cortexx2"
> + "cortexa34,cortexa35,cortexa53,cortexa57,cortexa72,cortexa73,thunderx,thunderxt88p1,thunderxt88,octeontx,octeontxt81,octeontxt83,thunderxt81,thunderxt83,ampere1,emag,xgene1,falkor,qdf24xx,exynosm1,phecda,thunderx2t99p1,vulcan,thunderx2t99,cortexa55,cortexa75,cortexa76,cortexa76ae,cortexa77,cortexa78,cortexa78ae,cortexa78c,cortexa65,cortexa65ae,cortexx1,ares,neoversen1,neoversee1,octeontx2,octeontx2t98,octeontx2t96,octeontx2t93,octeontx2f95,octeontx2f95n,octeontx2f95mm,a64fx,tsv110,thunderx3t110,zeus,neoversev1,neoverse512tvb,saphira,neoversen2,cortexa57cortexa53,cortexa72cortexa53,cortexa73cortexa35,cortexa73cortexa53,cortexa75cortexa55,cortexa76cortexa55,cortexr82,cortexa510,cortexa710,cortexx2,demeter"
> (const (symbol_ref "((enum attr_tune) aarch64_tune)")))
> diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
> index e0bb447beb9eae74551d863505eb265737d36334..9b6f67dc592d8a447d6b28390c90abe5dcfa5f08 100644
> --- a/gcc/config/aarch64/aarch64.cc
> +++ b/gcc/config/aarch64/aarch64.cc
> @@ -537,6 +537,24 @@ static const struct cpu_addrcost_table neoversen2_addrcost_table =
> 0 /* imm_offset */
> };
>
> +static const struct cpu_addrcost_table demeter_addrcost_table =
> +{
> + {
> + 1, /* hi */
> + 0, /* si */
> + 0, /* di */
> + 1, /* ti */
> + },
> + 0, /* pre_modify */
> + 0, /* post_modify */
> + 2, /* post_modify_ld3_st3 */
> + 2, /* post_modify_ld4_st4 */
> + 0, /* register_offset */
> + 0, /* register_sextend */
> + 0, /* register_zextend */
> + 0 /* imm_offset */
> +};
> +
> static const struct cpu_regmove_cost generic_regmove_cost =
> {
> 1, /* GP2GP */
> @@ -652,6 +670,16 @@ static const struct cpu_regmove_cost neoversen2_regmove_cost =
> 2 /* FP2FP */
> };
>
> +static const struct cpu_regmove_cost demeter_regmove_cost =
> +{
> + 1, /* GP2GP */
> + /* Spilling to int<->fp instead of memory is recommended so set
> + realistic costs compared to memmv_cost. */
> + 3, /* GP2FP */
> + 2, /* FP2GP */
> + 2 /* FP2FP */
> +};
> +
Given that these values are the same as for Neoverse V1, I wonder
whether we should reuse the existing structures, like we do for
cortexa76. I can see there are arguments both ways though.
Arbitrary sharing could come back to bite us.
So let's keep this as posted.
> /* Generic costs for Advanced SIMD vector operations. */
> static const advsimd_vec_cost generic_advsimd_vector_cost =
> {
> @@ -2391,6 +2419,195 @@ static const struct tune_params neoversen2_tunings =
> &generic_prefetch_tune
> };
>
> +static const advsimd_vec_cost demeter_advsimd_vector_cost =
> +{
> + 2, /* int_stmt_cost */
> + 2, /* fp_stmt_cost */
> + 2, /* ld2_st2_permute_cost */
> + 2, /* ld3_st3_permute_cost */
> + 3, /* ld4_st4_permute_cost */
> + 3, /* permute_cost */
> + 4, /* reduc_i8_cost */
> + 4, /* reduc_i16_cost */
> + 2, /* reduc_i32_cost */
> + 2, /* reduc_i64_cost */
> + 6, /* reduc_f16_cost */
> + 3, /* reduc_f32_cost */
> + 2, /* reduc_f64_cost */
> + 2, /* store_elt_extra_cost */
> + /* This value is just inherited from the Cortex-A57 table. */
> + 8, /* vec_to_scalar_cost */
> + /* This depends very much on what the scalar value is and
> + where it comes from. E.g. some constants take two dependent
> + instructions or a load, while others might be moved from a GPR.
> + 4 seems to be a reasonable compromise in practice. */
> + 4, /* scalar_to_vec_cost */
> + 4, /* align_load_cost */
> + 4, /* unalign_load_cost */
> + /* Although stores have a latency of 2 and compete for the
> + vector pipes, in practice it's better not to model that. */
> + 1, /* unalign_store_cost */
> + 1 /* store_cost */
> +};
> +
> +static const sve_vec_cost demeter_sve_vector_cost =
> +{
> + {
> + 2, /* int_stmt_cost */
> + 2, /* fp_stmt_cost */
> + 3, /* ld2_st2_permute_cost */
> + 3, /* ld3_st3_permute_cost */
> + 4, /* ld4_st4_permute_cost */
> + 3, /* permute_cost */
> + /* Theoretically, a reduction involving 15 scalar ADDs could
> + complete in ~3 cycles and would have a cost of 15. [SU]ADDV
> + completes in 11 cycles, so give it a cost of 15 + 8. */
> + 21, /* reduc_i8_cost */
> + /* Likewise for 7 scalar ADDs (~2 cycles) vs. 9: 7 + 7. */
> + 14, /* reduc_i16_cost */
> + /* Likewise for 3 scalar ADDs (~2 cycles) vs. 8: 3 + 4. */
> + 7, /* reduc_i32_cost */
> + /* Likewise for 1 scalar ADDs (~1 cycles) vs. 2: 1 + 1. */
> + 2, /* reduc_i64_cost */
> + /* Theoretically, a reduction involving 7 scalar FADDs could
> + complete in ~6 cycles and would have a cost of 14. FADDV
> + completes in 8 cycles, so give it a cost of 14 + 2. */
> + 16, /* reduc_f16_cost */
> + /* Likewise for 3 scalar FADDs (~4 cycles) vs. 6: 6 + 2. */
> + 8, /* reduc_f32_cost */
> + /* Likewise for 1 scalar FADDs (~2 cycles) vs. 4: 2 + 2. */
Same “1 scalar” comments as for the N2 patch.
OK with those changes, thanks.
Richard
> + 4, /* reduc_f64_cost */
> + 2, /* store_elt_extra_cost */
> + /* This value is just inherited from the Cortex-A57 table. */
> + 8, /* vec_to_scalar_cost */
> + /* See the comment above the Advanced SIMD versions. */
> + 4, /* scalar_to_vec_cost */
> + 4, /* align_load_cost */
> + 4, /* unalign_load_cost */
> + /* Although stores have a latency of 2 and compete for the
> + vector pipes, in practice it's better not to model that. */
> + 1, /* unalign_store_cost */
> + 1 /* store_cost */
> + },
> + 3, /* clast_cost */
> + 10, /* fadda_f16_cost */
> + 6, /* fadda_f32_cost */
> + 4, /* fadda_f64_cost */
> + /* A strided Advanced SIMD x64 load would take two parallel FP loads
> + (8 cycles) plus an insertion (2 cycles). Assume a 64-bit SVE gather
> + is 1 cycle more. The Advanced SIMD version is costed as 2 scalar loads
> + (cost 8) and a vec_construct (cost 2). Add a full vector operation
> + (cost 2) to that, to avoid the difference being lost in rounding.
> +
> + There is no easy comparison between a strided Advanced SIMD x32 load
> + and an SVE 32-bit gather, but cost an SVE 32-bit gather as 1 vector
> + operation more than a 64-bit gather. */
> + 14, /* gather_load_x32_cost */
> + 12, /* gather_load_x64_cost */
> + 3 /* scatter_store_elt_cost */
> +};
> +
> +static const aarch64_scalar_vec_issue_info demeter_scalar_issue_info =
> +{
> + 3, /* loads_stores_per_cycle */
> + 2, /* stores_per_cycle */
> + 6, /* general_ops_per_cycle */
> + 0, /* fp_simd_load_general_ops */
> + 1 /* fp_simd_store_general_ops */
> +};
> +
> +static const aarch64_advsimd_vec_issue_info demeter_advsimd_issue_info =
> +{
> + {
> + 3, /* loads_stores_per_cycle */
> + 2, /* stores_per_cycle */
> + 4, /* general_ops_per_cycle */
> + 0, /* fp_simd_load_general_ops */
> + 1 /* fp_simd_store_general_ops */
> + },
> + 2, /* ld2_st2_general_ops */
> + 2, /* ld3_st3_general_ops */
> + 3 /* ld4_st4_general_ops */
> +};
> +
> +static const aarch64_sve_vec_issue_info demeter_sve_issue_info =
> +{
> + {
> + {
> + 3, /* loads_per_cycle */
> + 2, /* stores_per_cycle */
> + 4, /* general_ops_per_cycle */
> + 0, /* fp_simd_load_general_ops */
> + 1 /* fp_simd_store_general_ops */
> + },
> + 2, /* ld2_st2_general_ops */
> + 3, /* ld3_st3_general_ops */
> + 3 /* ld4_st4_general_ops */
> + },
> + 2, /* pred_ops_per_cycle */
> + 2, /* while_pred_ops */
> + 2, /* int_cmp_pred_ops */
> + 1, /* fp_cmp_pred_ops */
> + 1, /* gather_scatter_pair_general_ops */
> + 1 /* gather_scatter_pair_pred_ops */
> +};
> +
> +static const aarch64_vec_issue_info demeter_vec_issue_info =
> +{
> + &demeter_scalar_issue_info,
> + &demeter_advsimd_issue_info,
> + &demeter_sve_issue_info
> +};
> +
> +/* Demeter costs for vector insn classes. */
> +static const struct cpu_vector_cost demeter_vector_cost =
> +{
> + 1, /* scalar_int_stmt_cost */
> + 2, /* scalar_fp_stmt_cost */
> + 4, /* scalar_load_cost */
> + 1, /* scalar_store_cost */
> + 1, /* cond_taken_branch_cost */
> + 1, /* cond_not_taken_branch_cost */
> + &demeter_advsimd_vector_cost, /* advsimd */
> + &demeter_sve_vector_cost, /* sve */
> + &demeter_vec_issue_info /* issue_info */
> +};
> +
> +static const struct tune_params demeter_tunings =
> +{
> + &cortexa76_extra_costs,
> + &demeter_addrcost_table,
> + &demeter_regmove_cost,
> + &demeter_vector_cost,
> + &generic_branch_cost,
> + &generic_approx_modes,
> + SVE_128, /* sve_width */
> + { 4, /* load_int. */
> + 2, /* store_int. */
> + 6, /* load_fp. */
> + 1, /* store_fp. */
> + 6, /* load_pred. */
> + 2 /* store_pred. */
> + }, /* memmov_cost. */
> + 5, /* issue_rate */
> + (AARCH64_FUSE_AES_AESMC | AARCH64_FUSE_CMP_BRANCH), /* fusible_ops */
> + "32:16", /* function_align. */
> + "4", /* jump_align. */
> + "32:16", /* loop_align. */
> + 3, /* int_reassoc_width. */
> + 6, /* fp_reassoc_width. */
> + 3, /* vec_reassoc_width. */
> + 2, /* min_div_recip_mul_sf. */
> + 2, /* min_div_recip_mul_df. */
> + 0, /* max_case_values. */
> + tune_params::AUTOPREFETCHER_WEAK, /* autoprefetcher_model. */
> + (AARCH64_EXTRA_TUNE_CHEAP_SHIFT_EXTEND
> + | AARCH64_EXTRA_TUNE_CSE_SVE_VL_CONSTANTS
> + | AARCH64_EXTRA_TUNE_USE_NEW_VECTOR_COSTS
> + | AARCH64_EXTRA_TUNE_MATCHED_VECTOR_THROUGHPUT), /* tune_flags. */
> + &generic_prefetch_tune
> +};
> +
> static const struct tune_params a64fx_tunings =
> {
> &a64fx_extra_costs,
> @@ -15317,7 +15534,8 @@ fractional_cost
> aarch64_vec_op_count::rename_cycles_per_iter () const
> {
> if (sve_issue_info () == &neoverse512tvb_sve_issue_info
> - || sve_issue_info () == &neoversen2_sve_issue_info)
> + || sve_issue_info () == &neoversen2_sve_issue_info
> + || sve_issue_info () == &demeter_sve_issue_info)
> /* + 1 for an addition. We've already counted a general op for each
> store, so we don't need to account for stores separately. The branch
> reads no registers and so does not need to be counted either.
prev parent reply other threads:[~2022-03-16 16:28 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-16 14:49 Andre Vieira (lists)
2022-03-16 16:28 ` Richard Sandiford [this message]
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=mpta6dp9815.fsf@arm.com \
--to=richard.sandiford@arm.com \
--cc=Kyrylo.Tkachov@arm.com \
--cc=andre.simoesdiasvieira@arm.com \
--cc=gcc-patches@gcc.gnu.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).