> I'm generally of the opinion that the compiler should not compromise > the speed of well written code to cover whatever abomination somehow > manages to convince the autovectorizer to generate zero stride > lengths.
Just suppose we have a (runtime) variable stride like in x264. Here, as well as with general scatter (just an array of offset from a base address) we have no easy way of knowing whether the access is not overlapping. Thus, we need to conservatively assume overlap takes place and basically always have to assume the mem is "left to right". Even if the stride is statically known and large there can be overlap in case we cannot analyze the dataref. > My interest is in OpenMP/OpenACC where the multithreading already > destroyed all notion of left-to-rightness that the vectorizer tries so > hard to preserve. In these cases, the end-user has declared and > promised that the loop iterations are independent, and if it turns out > that's not the case, then that's on them. > > However, if riscv has the instructions and hardware to handle that case, > would it not naturally fall to the "scatter_store" expander to handle > these cases? This feeling like a back-end decision, to me. > Or, are you thinking of versioning it in gimple, somehow? I assume > this would require knowing how the backend instruction handles the > writes... would the plan be to never ask the backend to do something > in-order if it can't promise that? Yes, gimple/vect and I'm still undecided how to best ask the backend. Unfortunately, riscv's strided store only does unordered accesses and cannot switch like our scatters. If we always fell back to ordered scatters, it would likely impact performance (depends on the uarch of course) while versioning for stride > element size would allow us to always generate strided stores which are potentially faster. -- Regards Robin
