Re: [gomp] Challenges in Implementing OpenMP

[Paolo Bonzini <bonzini at gnu dot org>]

> Essentially, OpenMP restructures the original code. The above example is 
> incredibly simple, and only touches the surface of OpenMP's 
> complexities.

But it also highlights a strength of GCC: support for nested functions 
means that we get escape analysis for free.  Write it like this and it 
is much saner.

---
  #include <stdio.h>

  int main(void)
  {
      // this function encapsulates the parallel region defined by
      //    the OpenMP pragma
      void * par_proc(void * arg)
      {
        puts("Hello, World!\n");
        return NULL;
      }
      __gomp_parallel (par_proc, NULL);
  }
---

and in libgomp:

---
  static int num_procs;

  static void __gomp_init (void) __attribute__ ((__constructor__))
  {
    num_procs = sysconf(_SC_NPROCESSORS_CONF);
  }

  void
  __gomp_parallel (void (*f) (void *), void *arg)
  {
    if (num_procs == 1)
      f (arg);
    else
      {
        // an array of thread ids
        pthread_t * thread_ids = alloca(sizeof(pthread_t) * num_procs);

        // for each processor launch a thread
        for (n = 0; n < num_procs; ++n)
          pthread_create(&thread_ids[n],NULL,f,arg);

        // wait for threads to finish
        for (n = 0; n < num_procs; ++n)
          pthread_join(thread_ids[n],NULL);
      }
  }
---

This example becomes easy again.  libgomp is not a minor feat, an gomp.c 
is not, but less overwhelming than what your source code showed.

> 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. The implementation 
> for Fortran will, of course, be based on gfortran.

I think that it is feasible to target C at first, writing replacements 
of the parser incrementally, to be used only within OpenMP directives. 
The C++ parser should be taken into account, in order to make interfaces 
as simple as possible.  Then, it is possible to provide "OpenMP parsing 
hooks" into the parser, calling for example cp_parser_binary_expression 
or c_parser_binary_expression, and enable OpenMP pragmas for C++ as well.

Unluckily, the Fortran front-end would probably be different in this 
respect.

This would be only used for the toplevel code: I am not proposing 
sharing code with indirect calls within such a delicate part (speed-wise 
and correctness-wise) of the compiler, only a common interface to the 
outside world.  So the slow path would be taken only to start parsing 
OpenMP sections.

> An additional concern is to make GNU OpenMP portable across most 
> platforms. This at least needs to be considered during the design phase; 
> the initial implementation would likely be for i686 and x86_64 (Linux 
> and Windows) platforms, simply based on the availability of developers 
> and hardware.

There was a pthread implementation on top of Win32 at Cygnus.  And 
there's gthr.

Paolo