missed vectorization (was Some thoughts about steerring commitee work)

[Tim Prince]

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.