Hi Robin,
On 1/10/2024 8:00 AM, Robin Dapp wrote:
Hi Edwin,
This patch copies the vector reservations from generic-ooo.md and
inserts them into generic.md and sifive.md. Creates new vector crypto related
insn reservations.
In principle, the changes look good to me but I wonder if we could
split off the vector parts from generic-ooo into their own md file
(generic-vector-ooo or so?) and include this in the others? Or is
there a reason why you decided against this?
I forgot we could include other md files into another file (I'll double
check that there isn't anything fancy for including other pipelines),
but I also thought that eventually all the tunes would have their own
vector cost pipelines. Since all the pipelines should be tuned to their
cost model, they would be different anyway. If it would be simpler for
now, I could separate the files out.
A recurring question in vector cost model discussions seems to be how
to handle the situation when a tune model does not specify a "vector tune
model". The problem exists for the scheduler descriptions and the
normal vector cost model (and possibly insn_costs as well).
Juzhe just implemented a fallback so we always use the "generic rvv" cost
model. Your changes would be in the same vein and if we could split
them off then we'd be able to easier exchange one scheduler descriptions
for another one (say if one tune model wants to use an in-order vector
model).
I think I'm getting a bit confused. Is there a reason why we would want
to exchange scheduler descriptions like the example you provided? I'm
just thinking why a in-order model would want to use an ooo vector model
and vice versa. Please correct me if I got the wrong idea.
I also want to double check, isn't forcing all typed instructions to be
part of a dfa pipeline in effect removing a situation where a tune model
does not specify a "vector tune model"? At least from my testing with
the assert statement, I get ICEs when trying to run the testsuite
without the vector tune model even on gc.
There is also still the question of whether to set all latencies
to 1 for an OOO core but this question should be settled separately
as soon as we have proper hardware benchmark results. If so we
would probably rename generic-vector-ooo into
generic-vector-in-order ;)
Regards
Robin
I agree the latencies can be tweaked after we get those benchmarks :)
Edwin
