This is the mail archive of the
mailing list for the GCC project.
Re: GSoC 2010 Project Idea
- From: Dorit Nuzman <DORIT at il dot ibm dot com>
- To: Артем Шинкаров <artyom dot shinkaroff at gmail dot com>
- Cc: gcc <gcc at gcc dot gnu dot org>
- Date: Sun, 11 Apr 2010 23:25:22 +0300
- Subject: Re: GSoC 2010 Project Idea
- References: <firstname.lastname@example.org> <email@example.com>
> I have a project in mind which I'm going to propose to the GCC in terms
> Google Summer of Code. My project is not on the list of project ideas
> (http://gcc.gnu.org/wiki/SummerOfCode) that is why it would be very
> for me to hear any opinions and maybe even to find a mentor.
> 1. Project idea
> A brief project idea is to create an abstract layer for vectorized
> computations. This would allow to write a portable vectorized code.
> 2. State of the art
> Nowadays most of processors have a support for SIMD computations.
> problem is that each hardware has a different set of SIMD instructions:
> MMX+SSE+AVX, PowerPC Altivec, ARM iWMMXt, and so on. GCC supports most of
> architecture-specific instructions providing built-in functions. It is
> considerably convenient to use these functions when you want to optimize
> piece of code. The problem starts when you want to make this code
> It is not a very common task, and of course GCC has a vectorizer.
> Unfortunately, there are many examples which show that it is relatively
> for a human to find a right place in the code and vectorize it, but it
> extremely hard for the compiler to do the same. As a result we end up
> code which is not using the capabilities of the architecture.
> It would be much easier for the programmer to use an abstract layer to
> implement a vectorized code. A compiler should deal with the
> portability issues
> dispatching the code from the abstract layer to the particular
> architecture. My
> experience shows that there are no such a library for C/C++ that could
> the problem. There are some attempts like:
> it is only a small part of the idea, and unfortunately the development is
> suspended. Or maybe I am wrong and everything is already written?
Just some relevant/related prior art you may be interested in: one is the
LLVA virtual vector IR:
and there's also an ongoing work on generic vector support in cli on top of
the cli-branch of GCC - a preliminary report on early stages of that work
was presented at GROW'10 (http://ctuning.org/dissemination/grow10-04.pdf),
with hopefully some follow-ups later this year...
good luck with whatever GSoC project you ended up proposing!
> 3. Implementation
> First we need to introduce the SIMD abstract model functionality which
> mapped to the set of architectures we want to support. The difficulty is
> SIMD instruction sets from different architectures are not fully
> Then we want to write a set of "fake-SIMD" functions to be sure that our
> will be usable within the architecture without SIMD support.
> After that there is a question how to dispatch functions from the
> layer to the architecture layer. The trivial thing to do is just to map
> abstract layer functions to the built-in functions. Obviously it
> would not give
> the best performance. For example, loading the data from the unaligned
> into the SIMD register is much slower than loading the data from the
> memory. Altivec has an instruction vec_madd(a,b,c) which can be
> two instructions in SSE case: _mm_add_ps( _mm_mul_ps(a,b), c). It means
> some code optimizations are required.
> 4. Time constraints
> The GSoC gives 4 month to finish the project. It means that the
> timeline could be the following:
> 2 weeks -- discussions and design
> 1 week -- fake SIMD
> 3 weeks -- implementation of the main dispatcher
> 2 weeks -- benchmarks and testing
> * the first submission
> 1.5 month -- architecture specific dispatcher optimizations
> 0.5 month -- testing
> * the second submission
> This project can be continued in various ways:
> 1) Cost model for the dispatcher
> 2) Auto vectorizer + dispatcher
> 3) Integration with other languages
> And so on
> 5. Questions
> Should it be the library or the part of the language? What about
> of this abstract layer with a respect to the Larrabee (or similar) which
> provides 512-bit register for vectorized operations? And so on.
> These questions should be discussed considering the project time
> and the interest of the GCC. If anybody is interested in mentoring such a
> project please let me know and I would be happy to discuss all the
> anybody thinks that the project is hopeless, please let me know as well.
> Best regards,
> Artem Shinkarov
> Compiler Technology and Computer Architecture Group
> University of Hertfordshire