> 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?
Yes, that's the case, the latency is related to the number of processed elements. The same is true for strided loads/stores, which are just special-cased gathers/scatters. Right now gather/scatter costing on the vectorizer side is a bit coarse, though, and we still use scalar-load costs for some cases. In that sense, the element count is already accounted for, just in an odd way :) I think aarch64 works around that in the backend, detecting the gather scalar-load case and adjusting accordingly, but I'd rather have a vectorizer change. I'd hope we can land a vectorizer patch during stage 1. It might still make sense to open a riscv PR/bug on the side so we can fix the issue during stage3/4 in case the vectorizer patch doesn't land. -- Regards Robin
