Giovanni Bajo <[EMAIL PROTECTED]> wrote on 18/06/2007 15:06:48: > On 6/18/2007 1:26 PM, Dorit Nuzman wrote: > > > these 3 are actually not so simple... the main thing that's blocking 2 of > > them right now is that they need support for stores with gaps, which can be > > added except the other problem is that the vectorizer thinks it's not > > profitable to vectorize them (or rather 2 of them. as does ICC by the way). > > When you say "not profitable", is that target-dependent? I would be > satisfied when the vectorizer can vectorize it *but* prefer not to do it
that's a fair point. In the one case (the 3X3 matrices and loop-bounds=3) the vectorizer just can't handle sizes that don't evenly divide the vector-size. Even when that will be extended (by conceptually unrolling the loop by 4 to be able to pack into 3 vectors of size 4) it won't help this case cause the loop bound is only 3. This particular testcase fails to vectorize even without the newly added initial cost-model, just based on the fact that the loop-count is less than the vector-size (this is not a target dependent decision). ICC is reported to also choose to not vectorize this loop. The other two loops we just can't vectorize yet (both of which ICC chooses not to vectorize because it thinks it's not profitable). > because it can be done more efficiently on the specific target. > > Of course, it would interesting to still "force" the vectorizer to > produce the code, so to compare the vectorized version with the > non-vectorized version and see if it is really right. Is there (will > there be) an option to turn off cost-based estimation within the vectorizer? > the choice not to vectorize when the loop-bound is less than the vectorization factor is the only cost estimation that is hard coded. The rest of the cost model is controlled by the flag -fvect-cost-model. dorit > > Since the time you opened these PRs we came quite a bit closer to > > vectorizing these (the support for interleaved accesses and for multiple > > data-types were also required). It will be fun to add the last missing bit > > - the support for the stores-with-gaps. I hope we'll get to it before too > > long... > > Nice! I'm looking forward to it! > > > If you have other (hot) code examples that expose different missing > > features I think that's always interesting to know about (but if it's like > > the codes above then maybe it will not have much added value...). > > I have dozens and dozens of loops which I believe that could be > vectorized and are not. I don't whether they are related to > store-with-gaps or not, though. So, well, I'll open the bugreports and > let you do the analysys. Feel free to close them as duplicates if you > think they're not worth to keep opened on their own. > -- > Giovanni Bajo >
