missed vectorization (was Some thoughts about steerring commitee work)

[Janne Blomqvist]

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?. For ALLOCATE 
we could use posix_memalign instead of malloc, if that is available. 
OTOH, AFAIK on x86-64 malloc returns 16-byte aligned so perhaps it's not 
worth bothering about. I'm not sure how to teach the middle-end about 
alignment, but I'm sure there is some way..

2) Annotate variables and procedure interfaces to help the optimizers. I 
think about the only thing we do ATM is declaring pure procedures (incl. 
intrinsics if I read the spaghetti correctly) with DECL_IS_PURE. See 
31094, 31593, 20165, 32131.

3) Better analysis of array syntax. Basically recognizing certain 
patterns and reorganizing the loops so that they can be vectorized. This 
is hard work with limited applicability, and perhaps it's not really 
needed, provided we do (2) well (allowing the middle-end to reorder 
loops if needed)?

-- 
Janne Blomqvist