[Gomp-discuss] The plan ...

[Lars Segerlund]

 Hi everybody,

  You won't get the whole plan today, my computer didn't want to read 
the cd's with the material I brought with me home for the weekend.

  I did a quick and dirty draft which is more of an outline, please 
check it out, it is however lacking a lot in detail.

  If I should summarize it, I would say that it contains, let's start 
of with GENERIC now, finish it and then move on to the frontends and 
libs, but be VERY carefull that we get all the functionality in there 
from the beginning.

  I will look more at GENERIC and the openMP spec tonight, ( I have 
made a new set of cd's .. let's hope for the best ), and I will get back 
with the real plan as soon as I am sure It's reasonable.

  I do intend to include a lot more implementation detail in that one, 
with this draft I just wanted some morer opinions. And as I sain, I will 
try to be back tomorrow with something better.

 / Lars Segerlund.

 Here follows the draft plan for gomp:

  First it is clear that there are a number of goals that we want to target, 
such as different dependencies and targets for the implementation. I suggest 
that we aim to include rather than exclude systems and options to support, 
however only as long as this does not complicate the design unneccesary.

  Thus the overall targets should be along the folowing lines:

        It should be possible to easily retarget to any threading library.

        It should be possible to run the code without a threading library.

        It has to be easy to gain debugging and profiling information.

        It should minimize the work needed in other parts of gcc for support.


  1. Frontends.

   When it comes to frontends, I suggest that we try to extend the existing 
frontends to propagate the pragmas/comments that we need to process.
   I got the impression that this task would not be as unsurmountable as first 
thought after discussions on the mailing list.

   Should this not be possible, or rather to complex to acomplish, I believe 
that we have to build two small frontends, one with FORTRAN semantics, and one 
with C/C++ semantics, this due to the different scope of the languages.

  2. The 'middle end'.

   I suggest that we target GENERIC tree's in order to make gcc understand 
parrallell constructs, this in order to have a high level representation, and 
with some luck we can confine a lot of work to gimplify.c and friends.

   I think that we should have at least two two different attributes when it 
comes to the highest level of parrallell construct, parrallell and distributed. 
The difference between the two would be the code generated as for 'parrallell 
regions' or subroutines, this would also enable us to support HPF and 
distributed systems such as mpi or pvm in the future, without making our job 
harder.

   I think this is the best place to start off, and leave the backend and 
frontend until we have all the needed constructs in place.

   What we currently need to progress is a suggestion of what to include in our 
modification of the GENERIC trees, also note that we might have to break up and 
reorganize the trees we get from the frontends.
   
   Most of what we have to do is directly specified by the openMP standard, and 
I would suggest that we targeted the attributes assigned to the variables of a 
parrallell section firts, ( shared, private and so on ... ), since I think a 
lot depends on how hard it will be to communicate the restictions placed on the 
variables.

  3. Back end.

   With some luck, no further work should e required in the backend.

  4. Library.

   I suggest that we start out with support for linux threads, and keep a keen 
look at what is POSIX and not in order to keep the mechanisms we use compliant 
and therefore minimizing the problems in retargeting.

   I also suggest that we leave the work on the library until such a time that 
we have a clear picture of what the minimal required set of functions will be.

 / Lars.