[EMAIL PROTECTED] 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.