> 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. > 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. 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 ;) Regards Robin
