This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [gomp] Challenges in Implementing OpenMP


Scott Robert Ladd <coyote@coyotegulch.com> writes:

[ complex result of code transformation ]

| Essentially, OpenMP restructures the original code. The above example
| is incredibly simple, and only touches the surface of OpenMP's
| complexities. For example, OpenMP directives often contain clauses
| that define variable sharing among threads.
| 
| My feeling is that OpenMP processing should take place in the language
| parser. Given the differences in the parsers for C and C++, this looks
| to require separate modifications to those compilers. 

I apologize in advance for what might look like an unsolicited ad.
However, the topic raised by Scott concerns GCC, C++ and a domain I'm
interested in.  All three reasons I feel concerned :-)

[ Speaking as someone interested in parallel and distributed computations
in C++ (I don't speak for C or Fortran). ]  

The view here at TAMU, is slightly different.  Instead of augmenting
the language with CPP directives and whatnot that the programmer has
to manually keep track of, we prefer to realy on higher level
abstractions.  That is the approach taken and implemented by STAPL

  http://parasol.tamu.edu/compilers/research/STAPL/

There is another project initiated by Bjarne Stroustrup, which I know
more about (certainly more than STAPL :-)), called "The Pivot".

The Pivot is a general framework for static analysis and
transformations  of C++ programs.  One of the main goal is to provide
direct support for distributed and parallel computations in C++.
We believe that support through library is much more scalable, more
portable, more general than support through CPP and language
extensions that would require most of compiler rewrite.

The Pivot relies on a (potentially standard) internal program
representation.  Here is a 30-min slides overview of the 
"The Pivot"/IPR structure.

   http://www-unix.mcs.anl.gov/workshops/DSLOpt/Talks/DosReis.pdf

So, you can see my bias:  Keep the compiler simple, delegate
domain-specific semantics to domain-specific tools;  Keep the
abstraction high level, and delegate byte fiddling to the computer
scientists and equations to physisists/numericists.

Keeping the compiler simple also make it easier to figure out bugs and
fix them.  Just take GCC as an example :-)

-- Gaby


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]