public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Robin Dapp <rdapp.gcc@gmail.com>
To: Juzhe-Zhong <juzhe.zhong@rivai.ai>, gcc-patches@gcc.gnu.org
Cc: rdapp.gcc@gmail.com, kito.cheng@gmail.com, kito.cheng@sifive.com,
	jeffreyalaw@gmail.com
Subject: Re: [PATCH] RISC-V: Switch RVV cost model to generic vector cost model
Date: Wed, 10 Jan 2024 15:11:09 +0100	[thread overview]
Message-ID: <c0d87177-ef9b-403a-8659-724b9004ddb9@gmail.com> (raw)
In-Reply-To: <20240110095828.3863165-1-juzhe.zhong@rivai.ai>

Hi Juzhe,

> The reason we want to switch to generic vector cost model is the default
> cost model generates inferior codegen for various benchmarks.
> 
> For example, PR113247, we have performance bug that we end up having over 70%
> performance drop of SHA256.  Currently, no matter how we adapt cost model,
> we are not able to fix the performance bug since we always use default cost model by default.
> 
> Also, tweak the generic cost model back to default cost model since we have some FAILs in
> current tests.

So to recap:

 - Our current default tune model is rocket which does not have a vector
   cost model.  No other tune model except generic-ooo has one.

 - We want tune models with no vector cost model to fall back to the
   default vector cost model for now, later possibly the generic RVV
   cost model.

 - You're seeing inferior codegen for dynamic-lmul2-7.c with our generic
   RVV (not default) vector cost model (built with -mtune=generic-ooo?).

Therefore the suggestions is to start over freshly with the default
vector cost model?

>  /* Generic costs for VLA vector operations.  */
> @@ -374,13 +374,13 @@ static const scalable_vector_cost generic_vla_vector_cost = {
>      1, /* fp_stmt_cost  */
>      1, /* gather_load_cost  */
>      1, /* scatter_store_cost  */
> -    2, /* vec_to_scalar_cost  */
> +    1, /* vec_to_scalar_cost  */
>      1, /* scalar_to_vec_cost  */
> -    2, /* permute_cost  */
> +    1, /* permute_cost  */
>      1, /* align_load_cost  */
>      1, /* align_store_cost  */
> -    1, /* unalign_load_cost  */
> -    1, /* unalign_store_cost  */
> +    2, /* unalign_load_cost  */
> +    2, /* unalign_store_cost  */
>    },
>  };

So is the idea here to just revert the values to the defaults for now
and change them again soon?  And not to keep this as another default
and add others?

I'm a bit confused here :)  How does this help?  Can't we continue to
fall back to the default vector cost model when a tune model does not
specify a vector cost model?  If generic-ooo using the generic vector
cost model is the problem, then let's just change it to NULL for now?

I suppose at some point we will not want to fall back to the default
vector cost model anymore but always use the generic RVV cost model.
Once we reach the costing part we need to fall back to something
if nothing was defined and generic RVV is supposed to always be better 
than default.

Regards
 Robin


  reply	other threads:[~2024-01-10 14:11 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-10  9:58 Juzhe-Zhong
2024-01-10 14:11 ` Robin Dapp [this message]
2024-01-10 14:18   ` 钟居哲
2024-01-10 14:40   ` 钟居哲
2024-01-10 15:04     ` Robin Dapp
2024-01-10 15:15       ` 钟居哲
2024-01-10 15:36         ` Robin Dapp
2024-01-10 15:45           ` 钟居哲

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=c0d87177-ef9b-403a-8659-724b9004ddb9@gmail.com \
    --to=rdapp.gcc@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jeffreyalaw@gmail.com \
    --cc=juzhe.zhong@rivai.ai \
    --cc=kito.cheng@gmail.com \
    --cc=kito.cheng@sifive.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).