Juzhe wrote about this in another mailing thread, so I’m pasting it here and CCing him.
> Hi, Chen. Thanks for the patch. It's good to see scalar/vector cost patch > since I was planning to add it long time ago but I failed to do that. > - I think it's better to specify the ratio by tune info (-mtune/-mcpu), I > don't think we need to add param (not sure whether other RISC-V folks want > it). > - For non-integer ratio, I don't it's the common case that we should worry > about. But if you really want to handle such cases, I think > fractional-cost.h in aarch64 may be the good solution. > 2. For gather_load/scatter_store tests, it's surprising that I didn't > add -fno-vect-cost-model when I added those testcases （I think I wanted to > introduce no-cost-model for such cases previously). So adding > -fno-vecto-cost-model will be fine. - non-integer ratio: AArch64's fractional_cost looks like a good option. We could go further, allow the cost table itself to use fractional initial values, that will give more flexible tuning. However, I'm not sure it's really necessary, since the current cost model probably isn't accurate enough to need that kind of precision. To Jeff > I was thinking about using issue rate from the tune structure as a > reasonable proxy for how wide the scalar part of the design. Then you > compare that to the VL of the code you want to vectorize. If the scalar > bandwidth is >= the number of vector elements you're handling per vector > op, then the scalar loop is probably preferred. It's not exact, but it > doesn't rely on magic numbers. Perhaps not. Issue rate does not always equal to the scalar units, and VL itself does not change with the number of vector units. In that case, a design with 1, 2, or 4 vector units could end up with the same result, which is not what we want. -- Regards, Zhongyao
