Re: More vectorizer testcases?
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 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? 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
Re: More vectorizer testcases?
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
Re: More vectorizer testcases?
Giovanni Bajo [EMAIL PROTECTED] wrote on 17/06/2007 20:43:15: Hi Dorit, some years ago I posted these testcases to Bugzilla's GCC: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18437 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18438 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18439 It looks like none of those are vectorized as of GCC 4.3. I read today that you're asking for more vectorizer testsuite so I was wondering: 1) Shall we add a GCC bugzilla component for the vectorizer? Currently the bugs are filed under tree-optimization which might be a little toogeneric, these days. Maybe, I'm not sure. A lot of times the vectorizer missed-optimization bugs depend on other components of the compiler, so I don't know if filing them under a vectorizer component would help. I don't have a strong preference about this. 2) Do you need more testcases from geometric code like those above? Those 3 above are pretty simple in fact, so I doubt more complex ones can beof help, but I can extract something more from my code if you want... 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). 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... 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...). thanks! dorit -- Giovanni Bajo
