On Wed, 16 Jan 2008, Dorit Nuzman wrote: > > > > From the last GCC Summit we learned about (Fortran) Frontend Based > > Optimizations from Toon and it was suggested to tackle one issue by > > promoting arrays to a first-class middle-end type. Discussion with > > Sebastian also reveals that this makes sense to ease the analysis > > of the into-GRAPHITE transformation by not dropping information that > > cannot be re-computed. > > > > ... > > Maybe something like the infrastructure you propose could also fascilitate > supporting vectorization into "virtual vectors" (vectors whose size is > unknown)? (as raised in this thread: > http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00687.html - i.e. to > vectorizer w/o knowing any target specific info, including vector sizes). > (Or is there a different way to express such a thing?) > > This would also let us split the vectorizer into a target-independent part, > that uses the vector size as a parameter, followed by a target dependent > part that materializes the vectors into actual vectors as supported by the > target (including alignment handling, etc). The target dependent part would > be invoked when the target machine is known at compile time. For cases when > you use dynamic/JIT compilation (e.g. targets like > http://gcc.gnu.org/projects/cli.html) the target dependent part would take > place during JIT compilation later on.
Hm, can't you just use arbitrary middle-end vector types now? You probably have to give them BLKmode (as no HW vector mode might exist for arbitrary sizes), but everything else would just work. The array types would be mainly introduced to allow arbitrary dimensional data types, which we do not allow in expressions currently. But yes, a one-dimensional array could then also be viewed as vector. I don't have a strong opinion on whether the real VECTOR_TYPEs should be constrained to ones mappable to a real machine mode or not (I guess we'll just experiment). > > Another point for the motivation is that vector constructs should > > survive till the point where GCC knows/uses information about the > > vector target machine with using the vectorizer (as part of the > > GRAPHITE framework) to create regular (optimized) scalar IL from > > the array operations. > > > > (Just to clarify - when you say "using the vectorizer to create regular > scalar IL" from whole-array constructs, you mean a "scalar IL" that also > includes the kind of operations on vector types we have today, right?) Right. That was for the time the vectorizer works on the GRAPHITE IL. > Until such time when the vectorizer is incorporated in GRAPHITE, the > vectorizer could already benefit from preserving whole-array operations (by > avoiding the introduction of redundant dependences/order-constraints). > However, the early lowering you require means that we can't keep the array > expressions around until vectorization in its current location. Is that a > strict restriction? Can this IL extension live longer? In principle the IL can live until expansion to RTL, but the usual scalar optimizers will not work on these parts, so the trade-off is either lowering early and have the scalar optimizers optimize or lowering later and depend on the lowering process to generate optimized code already. Again, we have to experiment with that. I also hope to have something ready to present at the Summit about this. Thanks, Richard.
