> Yeah, common_vector_cost is another way to model this. > > I’m just trying to make the cost-model rules clearer instead of hiding > them in magic numbers. > Otherwise, it may be hard to tell later whether a vector cost for a > given uarch already includes the unit-ratio scaling.
Originally, my idea was to have a target knob to enable this kind of costing but that might further complicate things, rather than simplify... Bohan's approach is the basic one that we also used for a while but we want to do better than that in the future. Therefore, I would suggest something similar to what I proposed in the original thread about this: Let's introduce a function that (for now, crudely) estimates things. If a uarch doesn't want or need the new scaling, it can still opt out by disabling the scaling (which already is the default). I'll note that the insn scheduler for generic-ooo assumes one vector unit. We might want to extend this. I'd say this is good to go but for documentation purposes, let's introduce a function scale_vector_costs or something right away and add a comment/TODO that we should try to estimate throughput as well as the critical path. -- Regards Robin
