This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] BB vectorizer and vectorizer reorganization


2008/11/10 Ira Rosen <IRAR@il.ibm.com>:

> - The thought is to invoke the bb-vectorize pass right after the unrolling
> pass which follows the loop-vectorizer (before auto-par pass), thereby
> letting the loop-aware BB-vectorizer have a go first (within the
> loop-vectorizer), taking advantage of the loop-context if possible.
> Alternatively, we may want to consider scheduling it after all the loop
> optimizations (as it doesn't use the loop context at all), however that
> requires rewriting portions of the data-ref analysis.

How about deriving the ordering from one of the phase ordering tools
we have available?  Much easier to make a decision then (and it will
help pruning out dependency bugs in the initial implementation).

> - We'll introduce a new flag -fbb-vectorize, that we plan to turn on by
> default when -ftree-vectorize is set.

Is a new flag really needed?  Are there cases where one would want
only SLP-style vectorization?

> - Data-refs analysis is a reduced data-refs analysis that ignores any
> evolution and any loop data dependences if exist (in other words we are
> completely unaware here of the loop context).

Aren't you specifically targetting code outside loops?  Not quite sure
how this is significant other than you will treat loop-carried
dependencies as vectorization barriers.


Diego.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]