[RISC-V] vector segment load/store width as a riscv_tune_param

[Robin Dapp]

> I am revisiting an effort to make the number of lanes for vector segment
> load/store a tunable parameter.
>
> A year ago, Robin added minimal and not-yet-tunable
> common_vector_cost::segment_permute_[2-8]

But it is tunable, just not a param? :)  We have our own cost structure in our 
downstream repo, adjusted to our uarch.  I suggest you do the same or upstream 
a separate cost structure.  I don't think anybody would object to having 
several of those, one for each uarch (as long as they are sufficiently 
distinct).

BTW, just tangentially related and I don't know how sensitive your uarch is to 
scheduling, but with the x264 SAD and other sched issues we have seen you might 
consider disabling sched1 as well for your uarch?  I know that for our uarch we 
want to keep it on but we surely could have another generic-like mtune option 
that disables it (maybe even generic-ooo and change the current generic-ooo to 
generic-in-order?).  I would expect this to get more common in the future 
anyway.

> Some issues & questions:
>
> * Since this pertains only to segment load/store, why is the word "permute"
>   in the name?

The vectorizer already performs costing for the segment loads/stores (IIRC as 
simple loads, though).  At some point the idea was to explicitly model the 
"segment permute/transpose" as a separate operation i.e.
 
 v0, v1, v2 = segmented_load3x3 (...)
   {
     load vtmp0;
     load vtmp1;
     load vtmp2;
     v0 = {vtmp0[0], v1tmp[0], v2tmp[0]};
     v1 = {vtmp0[1], v1tmp[1], v2tmp[1]};
     v2 = {vtmp0[2], v1tmp[2], v2tmp[2]};
   }

and that permute is the expensive part of the operation in 99% of the cases.
That's where the wording comes from.

> * Nit: why are these defined as individual members rather than an array
>   referenced as segment_permute[NF-2]?

No real reason.  I guess an array is preferable in several ways so feel free to 
change that.

> * I implemented tuning as a simple threshold for max NF where segment
>   load/store is profitable. Test cases for vector segment store pass, but
>   tests for load fail. I found that common_cost_vector::segment_permute is
>   properly honored in the store case, but not even inspected in the load
>   case. I will need to spelunk the autovec cost model. Clues are welcome.

Could you give an example for that?  Might just be a bug.
Looking at gcc.target/riscv/rvv/autovec/struct/struct_vect-1.c, however I see 
that the cost is adjusted for loads, though.

-- 
Regards
 Robin