> Current generic cost model makes dynamic-lmul2-7.c generate inferior codegen.
>
> I found if I tweak the cost a little bit then dynamic-lmul2-7.c codegen can
> be recovered.
> However, it makes other tests failed....
> It's complicated story....
Ok, makes sense. So the plan seems to be:
(1) Fall back to the generic cost model if the tune model didn't
specify one, i.e. make sure we always use the generic cost
model rather than the default one.
(2) Change this generic (fallback) cost model so we don't have
regressions on the current trunk, as it's now always used.
(3) Adjust it piece by piece.
Sure this makes sense and is also what I had in mind.
> It's true that: we can keep current cost model
> default_builtin_vectorization_cost
> And tweak generic cost model, for exampl, add testcase for SHA256 and add
> -mtune=generic-ooo to test it.
> But the question, how do you know whether there is a regression on current
> testsuite with -mtune=generic-ooo ?
That's a valid question and not easily solved. Ideally the
generic model is generic enough to be a good base for most
uarchs. Then the uarchs would only do minor adjustments and
have their own tests for that while the bulk of the generic
tests would still pass.
Generally, normal tests should be pretty independent of the
cost model with the exception of checking instruction sequences.
Those that are not should either specify their own -mtune and/or
disable scheduling. Of course that's easier said than done...
Back to the patch:
I would suggest either renaming generic_vl[sa]_vector_cost to
rvv_vl[sa]_vector_cost (I find generic a bit too close to default)
and/or add comments that those are supposed to be the vector cost models
used by default if no other cost model was specified.
After understanding (2) of the plan the patch is OK to me with
that changed.
Regards
Robin
