Re: [Gomp-discuss] The draft ... issues

[Steven Bosscher]

Since I parties a bit too much last night, I'll keep it with spell fixes
for today and give you some actually useful (well at least I hope)
feedback tomorrow :-)

Oh, can you use two blanks between new sentences?  Makes the tex a bit
more readable and also saves us some work if we rewrite this doc to
texinfo and make it part of gcc documentation (at some point in the far
future :-)

Greetz
Steven

*** gompspec.tex~       Thu Mar 13 10:35:11 2003
--- gompspec.tex        Thu Mar 13 10:41:14 2003
***************
*** 8,18 ****
  \abstract{We discuss the possible infrastructure for our OpenMP realisation}
  %
  \section{Introduction}
! This document discuss how to made concurrency-aware the current
! realisation of the Gnu Compiler Collection (GCC). The goal of the model
  discussed here is to set up a framework for introducing OpenMP directives
! in the compiler(s) and and provide a general concurrency aware framework for
! gcc internals. In our ambition this framework would be able to handle all
  forms of concurrency and memory models. However, when that fails or introduces
  too many extra complications we temporarily revert to the objective of
  handling the OpenMP model. In our discussion we try to underline what is
--- 8,18 ----
  \abstract{We discuss the possible infrastructure for our OpenMP realisation}
  %
  \section{Introduction}
! This document discusses how to bring concurrency-awareness to the current
! realisation of the GNU Compiler Collection (GCC). The goal of the model
  discussed here is to set up a framework for introducing OpenMP directives
! in the compiler(s) and to provide a general concurrency aware framework for
! GCC internals. In our ambition this framework would be able to handle all
  forms of concurrency and memory models. However, when that fails or introduces
  too many extra complications we temporarily revert to the objective of
  handling the OpenMP model. In our discussion we try to underline what is
*************** will expose a still incomplete, very mod
*** 30,36 ****
  %
  \section{From Directives to IR}
  To be concrete, we consider the C/C++ specifications\footnote{For the moment,
! due to issues with the g77 front-end and to the youth of the g90 front-end,
  we leave Fortran aside. We stress however that the IR level is
  language-independent, so it will not be a major problem to tackle Fortran,
  once the issues with the front-ends will be solved.} for OpenMP ({\bf Scott:
--- 30,36 ----
  %
  \section{From Directives to IR}
  To be concrete, we consider the C/C++ specifications\footnote{For the moment,
! due to issues with the g77 front-end and to the youth of the g95 front-end,
  we leave Fortran aside. We stress however that the IR level is
  language-independent, so it will not be a major problem to tackle Fortran,
  once the issues with the front-ends will be solved.} for OpenMP ({\bf Scott:
*************** section~\ref{subs:threadcreation}.} 
*** 53,61 ****
  \label{subs:threadcreation}
  On entering a parallel regions, the program will fork the appropriate number
  of threads, as specified in the order by a call to 
openmp\_set\_num\_threads(),
! the corresponding environment variable and the default. What characterise a
! thread are the list of the variable shared among the threads, the list of
! the variables private to each thread and the code to be executed by a thread.
  At the frontend level, we should create a scheme for the threads suitable for
  the tree representation. Essentially, a program section that looks like
  \begin{verbatim}
--- 53,61 ----
  \label{subs:threadcreation}
  On entering a parallel regions, the program will fork the appropriate number
  of threads, as specified in the order by a call to 
openmp\_set\_num\_threads(),
! the corresponding environment variable and the default. Each thread is
! characterized by a list of the variable shared among the threads, another list
! of the variables private to the thread, and the code to be executed by the 
thread.
  At the frontend level, we should create a scheme for the threads suitable for
  the tree representation. Essentially, a program section that looks like
  \begin{verbatim}
*************** Note that the private variable must be i
*** 93,99 ****
  while the shared variable is inherited from the serial part.
  
  This should be enough, the other fork/join cases can be reduced to this one.
! Let's see it case by case
  \begin{enumerate}
  \item {\em for directive within a parallel directive}:
  \label{fordir}
--- 93,99 ----
  while the shared variable is inherited from the serial part.
  
  This should be enough, the other fork/join cases can be reduced to this one.
! Let's see it case by case,
  \begin{enumerate}
  \item {\em for directive within a parallel directive}:
  \label{fordir}
*************** Note also that although we have started 
*** 111,118 ****
  the structure to which we arrive is general and can be used by any threading
  model. ({\bf not sure though about the generality of the minimal subset.})
  
! That structure is then propagated to the Middle End and will be the basis for
! the intermediate representation. What we do from here on will depend:
  (a) on the Optimisation framework ({\bf still no clue from my behalf for the
  time being}); (b) on the chosen threading implementation. 
  For (b), a good starting point is the Posix model. Note however
--- 111,118 ----
  the structure to which we arrive is general and can be used by any threading
  model. ({\bf not sure though about the generality of the minimal subset.})
  
! That structure is then propagated to the GCC middle end and will be the basis
! for the intermediate representation. What we do from here on will depend:
  (a) on the Optimisation framework ({\bf still no clue from my behalf for the
  time being}); (b) on the chosen threading implementation. 
  For (b), a good starting point is the Posix model. Note however
*************** by another thread. If the programmer wan
*** 137,140 ****
  visible to all threads, it must explicitely flush it to memory (with all the
  implications this will have for the update of the cached copy...).
   
! \end{document}
\ No newline at end of file
--- 137,140 ----
  visible to all threads, it must explicitely flush it to memory (with all the
  implications this will have for the update of the cached copy...).
   
! \end{document}