https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81616
--- Comment #16 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Jan Hubicka from comment #13) > > So is this option still helping with the latest microcode? Not in this case > > at > > least. > > It is on my TODO list to re-benchmark 256bit vectorization for Zen. I do not > think microcode is a big difference here. Using 256 bit vectors has > advantage > of exposing more of parallelism but also disadvantage of requiring more > involved setup. So for loops that vectorize naturally (like matrix > multiplication) it can be win, while for loops that are difficult to > vectorize > it is a loss. So I think the early benchmarks did not look consistent and it > is > why 128bit mode was introduced. > > It is not that different form vectorizing for K8 which had split SSE > registers > in a similar fashion or for kabylake which splits 512 bit operations. > > While rewriting the cost-model I tried to keep this in mind and more > acurately > model the split operations, so it may be possible to switch to 256 by > default. > > Ideally vectorizer should make a deicsion whether 128 or 256 is win for > partiuclar loop but it doesn't seem to have infrastructure to do so. > My plan is to split current flag into two - preffer 128bit and assume > that registers are internally split and see if that is enough to get > consistent > win for 256 bit vectorization. > > Richi may know better. The vectorizer cannot currently evaluate both (or multiple) vector length vectorization costs against each other. Doing so with the current implementation would have prohibitive cost (basically do the analysis phase twice and if unlucky and the "first" wins, re-do analysis phase of the winner). Hmm, maybe not _too_ bad in the end... But first and foremost costing is not aware of split AVX256 penalties, so I'm not sure if doing the above would help. I can cook up some "quick" prototype (maybe hidden behind a --param paywall) so one could benchmark such mode. Is there interest? > Honza
