This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: missed vectorization (was Some thoughts about steerring commitee work)


blomqvist.janne@gmail.com wrote:
Tim Prince wrote:
There are several issues. EQUIVALENCE produces such a problem (PR32373) as do various kinds of references to multiple sections of the same array (PR32375,32376,32377,32378,32379,32380). Only 2 of those PRs involve actual source/destination overlap, where the vectorizer would have to choose the correct direction (loop reversed or not).
In the bigger case (PR32380) there are loops which vectorize in isolation but not in the presence of other loops.

Vectorization is tough work, and in the end if you succeed noone cares except for the crystallography weenies (and pipe stress freaks, if you catch my drift). ;-/


That being said, for the gfortran frontend there are a few things we can do to help the vectorizer:

1) Keep our data 16-byte aligned, this could help 32380?.
In the actual application 32380 is derived from, the initial index is 1 (16-byte aligned) 99% of the time. Some of those loops do vectorize with gfortran when taken in isolation. As all the arrays are set the same addresses, modulo 32 bytes, any required alignment adjustments for the rare cases are the same for all.
Recent public statements indicated that applications like these account for >25% of the "server" business of the largest vendors (more than that for their competitors), and this fraction is growing. While this may not fit those who use gcc compilers, once the effort has been made to support vectorization, it may be of interest to see whether the boundaries could be extended.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]