This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Some thoughts about steerring commitee work
- From: Dorit Nuzman <DORIT at il dot ibm dot com>
- To: "Daniel Berlin" <dberlin at dberlin dot org>
- Cc: "Eric Botcazou" <ebotcazou at libertysurf dot fr>, gcc at gcc dot gnu dot org, "H. J. Lu" <hjl at lucon dot org>, "Ian Lance Taylor" <iant at google dot com>, Ira Rosen <IRAR at il dot ibm dot com>, "Vladimir N. Makarov" <vmakarov at redhat dot com>
- Date: Mon, 18 Jun 2007 15:28:50 +0300
- Subject: Re: Some thoughts about steerring commitee work
>
> > 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