> > > However, as far as I know (also from talking with the > > SLP authors) pretty much all the opportunities they had found at the time > > were in loops. > > I can hand you more than the testcases i've given so far. There is > tons of code out there that would benefit from straight line
Interesting. I wasn't aware of this potential. Please do send some of this code. thanks! > vectorization. In fact, we have some that gets written in loop form > right now just so it gets vectorized! > that doesn't sound like such a bad idea to me... :-) (seriously - isn't it more intuitive for the programmer and informative for the compiler to use loops when possible? of course, I haven't seen the code you're talking about so maybe it doesn't apply to the cases you're referring to) > > > we'll have to have a much better cost model before we start packing random > > sequences of stmts out of loops. > > This i'm happy to agree on, but it does not change that I am > disappointed that you have tied the SLP implementation to loops so > heavily. > I think the "SLP" that we did should really be viewed more as extending the vectorizer to also consider intra-iteration DLP (in addition to inter-iteration DLP). We used the term SLP cause there is a lot of analogy to SLP, and a lot of people are familar with this term, but we are not doing SLP per se. And, as I said before, I see the dependence on the existing loop infrastructure as an advantage, and a way to efficiently vectorize a lot of SLP-like-codes without writing a whole new vectorizer. I don't debate that there's room to also implement real basic-block SLP (well, at least now that I hear that there's ton of code that can benefit from it), but I don't think you should be so disappointed... :-) thanks, dorit > > > > > Simply because you can't find cases in SPEC2000 doesn't mean it's not > > useful. > > > > I don't know where you're taking this from. SPEC2000 is really not so > > interesting vectorization wise, inside or outside loops. > > This was from some private mails I received about how it is not useful > for "benchmarks". > HTH, > Dan
