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
- Re: missed vectorization (was Some thoughts about steerrin... Janne Blomqvist
-
