Hi Robin,
Thanks for reviewing the patch!
> Heh, we used similarly high values internally. I was hoping we'd cost gathers
> a bit better now but perhaps the common-code changes weren't enough.
The high cost (99/32) mainly comes from the case where the index type is e8
— in that scenario the latency is quite high on our implementation. I chose the
worst-case value to be conservative. I'm curious whether on your side the
gather/scatter latency also varies depending on the index element type?
If so, we could potentially refine the cost model further by differentiating
based
on the index type.
> The store costs seem a bit low. Is this intended?
Yes, this is intended. The aligned store latency on the C950 is indeed 1 cycle,
so the cost reflects the actual hardware behavior.
> Out of curiosity, did you fold scalar throughput/vector throughput into the
> costs? I.e. a factor of 2 for 4 scalar units vs 2 vector units?
Currently the costs only account for latency. I agree that factoring in the
throughput ratio would be a good improvement.
> Just FYI, you should be able to use -fno-tree-loop-distribute-patterns.
> Doesn't matter a lot here, though.
Thanks for the tip.
Best regards,
Yaduo
