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.
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.
Yeah, the confusion is understandable as it's all in flow and several
things I mentioned are artifacts of us not yet being stabilized (or
actually having hard data to base our decisions on).
Usually, once a uarch has settled there is no reason to exchange
anything, just smaller tweaks might be done. I was more thinking of
the near to mid-term future where larger changes like ripping out
one thing and using another one altogether might still happen.
Regarding out of order vs in order - for in-order pipelines we will
always want to get latencies right. For out of order it is a balancing
act (proper latencies often mean more spilling and the processor will
reorder correctly anyway).
So you're mostly right that the argument is not very strong as soon
as we really know what to do and not to do.
That makes sense to me!
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 are (at least) three parts of the "tune model":
- vector cost model, specifying the cost of generic vector operations,
not necessarily corresponding to an insn
- insn cost, specifying the cost of an individual insn, usually close
to latency but sometimes also "complexity" or other things.
- insn latency and other hardware scheduler properties.
We can leave out any of those which will make us fall back to default
values. Even if we forced a scheduler description we could still have
the default fallback for the other two and generate unfavorable code
as a result.
So if I'm understanding things correctly, the costs the Juzhe is working
on in riscv.cc would be part of the vector cost model since they don't
correspond to individual instructions and only target vector code. These
costs would be the default fallback in the event of having no scheduler
descriptions for the insn.
The vector pipelines I'm working describes the insn latency categorized
by the insn type. The scheduler will attempt to generate favorable code
by this description but also consider the vector cost model. That is,
it's possible for an insn with a latency of 1 and cost of 10 to be
replaced by an insn with a latency of 2 and cost of 3.
The insn cost is the cost of every insn which can be specified
elsewhere. These override the values in the vector cost model for vector
insns? Where are these specified?
Then, all of these combined form a tune model like generic-ooo or rocket.
However, this is of course not desirable and we will soon have a
reasonable vector cost model that corresponds to the non-uarch
specific properties of the vector spec. Once this is in place
we will also want a somewhat generic vector scheduler description
that goes hand in hand with that. Despite the name, the vector
part of generic-ooo could be used for in-order vector uarchs and
we might want to define a different description for out-of-order
uarchs. That's a separate discussion but at least for that
contingency it would make sense to easily interchange the scheduler
description ;)
I think I understand everything. I'm currently testing a run with a
generic-vector-ooo file and I'm a little unsure how we would create a
second generic-vector-in-order file such that each insn maps only to one
reservation without using tune attributes but I guess that will be an
implementation detail for later :)
Edwin
