On 5/27/2026 2:04 AM, Robin Dapp wrote:
+static const common_vector_cost xt_c9501_vls_vector_cost = {
+ 3, /* int_stmt_cost */
+ 4, /* fp_stmt_cost */
+ 99, /* gather_load_cost */
+ 32, /* scatter_store_cost */
Heh, we used similarly high values internally. I was hoping we'd cost gathers
a bit better now but perhaps the common-code changes weren't enough.
Yea. I continue to be fairly skeptical of the performance of indexed
loads/stores on RISC-V from a performance standpoint.
One of the things we probably are going to want to do as we see higher
performing cores coming to market is evaluate trends and adjust the
generic models based on those trends. Not anything Wang needs to do,
more a note for Robin and myself.
+ 8, /* segment_permute (2) */
+ 9, /* segment_permute (3) */
+ 9, /* segment_permute (4) */
+ 12, /* segment_permute (5) */
+ 12, /* segment_permute (6) */
+ 12, /* segment_permute (7) */
+ 12, /* segment_permute (8) */
+ 2, /* vec_to_scalar_cost */
+ 2, /* scalar_to_vec_cost */
+ 4, /* permute_cost */
+ 6, /* align_load_cost */
+ 1, /* align_store_cost */
+ 8, /* unalign_load_cost */
+ 2, /* unalign_store_cost */
The store costs seem a bit low. Is this intended?
I would guess that getting the store issued as quickly as possible after
its inputs are resolved is helpful because it usually closes the live
range from the compiler's standpoint. We've certainly seen that being
generally useful when looking at scheduler models.
I'd kind of expect higher performance designs like this one to benefit
from overlap_op_by_pieces. I'd expect the branch cost to be higher to
encourage the compiler to if-convert aggressively to avoid branch
mispredictions, but I'm not at all familiar with this core, so I'd go
with Wang's recommendation here.
I'd be particularly curious if this design is showing that the
zero-stride-load idiom is meaningfully faster than the alternatives. I
think that would be the first core where this was true.
Anyway, it's all sensible to me. If there's fine tuning to do, that can
certainly happen as followups IMHO.
jeff
