Hi Zhongyao, > I still need your written feedback on this patch. the call last night > wasn't quite clear to me. > > Also I agree that we don't need the fractional-cost for now, not > really necessary.
I still wanted to think about this a bit. Richi argues that even wide OoO cores don't reach the fully-unrolled limit of their scalar issue rate and therefore a simplistic comparison overestimates scalar throughput. I think the smaller the loop the more valid this concern is. If the loop already has high scalar ILP it works reasonably well according to our experience. Of course it's difficult to statically estimate the uarch properties that play into this. Depending on the uarch vectorizing only very clear cases might make sense (but the opposite can hold as well). What would help is an estimate of the critical path as well as estimates of various factors that might influence ILP (loop size, taken branch throughput, IV overhead, reduction etc.). I'm making things up on the fly but maybe a maximum over (insns_per_iter / scalar ILP, taken_branches_per_cycle, reduction_latency, ...) would be a better scalar estimate. For a better vector estimate we'd need to factor in reduction and gather/scatter latency which limits ILP, i.e. a critical-path question again. As long as we don't have that and short- to mid-term, I don't think a crude estimate is too bad and we can always refine as well as make it opt-in for the time being? Adding scalar_units and vector_units to the tune struct (vs re-using issue_rate) might work but would might fall flat for divisions and other ops that are only issued to one unit? So in order to make some kind of progress (and perhaps being able to test things), I would suggest making the mechanism opt-in in the tune struct (yay, even more fields!) as well as adding scalar_units as well as vector_units. Then scale by that factor with some exceptions like you already have. Now that we "force" unroll smaller loops, the scalar estimate might actually be slightly better :) Once that is in place, we can add exceptions one by one, like e.g. factoring in reduction latency or even try a simplistic critical-path estimator? Long-term we surely want something like aarch64's vec_issue_info, perhaps for scalar as well, to help us with costing. -- Regards Robin
