This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: A bit of vector extension documentation
- To: Diego Novillo <dnovillo at redhat dot com>
- Subject: Re: A bit of vector extension documentation
- From: Daniel Berlin <dan at cgsoftware dot com>
- Date: Fri, 28 Sep 2001 18:36:57 -0400
- Cc: David Edelsohn <dje at watson dot ibm dot com>,Richard Henderson <rth at redhat dot com>,Daniel Berlin <dan at cgsoftware dot com>, Daniel Egger <degger at fhm dot edu>,gcc-patches at gcc dot gnu dot org, gcc at gcc dot gnu dot org
- References: <rth@redhat.com> <200109281712.NAA23750@makai.watson.ibm.com><20010928132532.A10203@tornado.cygnus.com>
Diego Novillo <dnovillo@redhat.com> writes:
> On Fri, 28 Sep 2001, David Edelsohn wrote:
>
>> >>>>> Richard Henderson writes:
>>
>> Richard> On Fri, Sep 28, 2001 at 11:48:31AM -0400, Daniel Berlin wrote:
>> >> It's based on the algorithms in the paper "Exploiting superword level
>> >> parallelism with multimedia instruction sets"
>> >> http://www.acm.org/pubs/citations/proceedings/pldi/349299/p145-larsen/
>>
>> Richard> Yes, I've seen that one. While a nice starting point, I don't
>> Richard> think it's as powerful as some of the other loop-based vectorization
>> Richard> algorithms.
>>
>> I thought the point of the paper is that it is a generalization
>> that does not require loops. For SIMD, as opposed to vector,
>> architectures, it might be better because it can take advantage of such
>> instructions without the loop setup overhead.
>>
> Yes, the paper does not attempt to design a vectorizing compiler.
> It merely points out that in several cases you can get away with
> converting sequence of expressions into SIMD instructions. They
> do have the limitation of working on single basic blocks, though.
Sure, but this includes basic blocks inside loops.
Won't this take care of the majority of cases anyway?
>
> Diego.
--
"Everywhere is walking distance if you have the time.
"-Steven Wright