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 via email to