Re: [Gomp-discuss] CIL representation ...

[Diego Novillo]

On Wed, 2003-03-12 at 09:50, Lars Segerlund wrote:

>   On the list we decided to try to make the internal representation 
> independent of the memory or parallel model ( or atleast capable of 
> representing different ones ), ( a cople of days ago ).
> 
Well, you can't make things so generic that they become impractical to
analyze and optimize.  My suggestion is to start with small building
blocks that you can later combine to produce more complex patterns.  In
my experience, you rarely need anything other than fork/join and
parallel loops.  Heck, even if you only had fork/join, you could
represent the other.

The memory model is trickier because that one pervades everything and is
not represented syntactically in the program.  Usually, it is dictated
by your parallel environment or the language.  The trick there is that
when you see an assignment to a shared variable V, the compiler may not
always assume that V will be immediately available everywhere.  It may
be that V is propagated at the next synchronization point, or maybe V is
only available when you enter or leave a mutex, or maybe you need a
specific flush command to make V available everywhere.

The only thing you can do is stick to the memory model dictated by
whatever standard you are following: be it OpenMP or CIL or Java. 
You'll have to code the memory model as a global property for the
language or target that you are compiling for.


>   And with this in mind, do you think that a representation such as CIL 
> is able to cover these cases ? My objection is how to construct the 
> necessary graphs since the control parallism is available through 
> mechanisms ( locks, mutexes, restrictions ) instead of symbolic form ( 
> graph ).
> 
I'm not familiar with CIL, sorry.  If you have a URL for it, I may be
able to give you a more informed opinion.  However, I don't understand
why you want a graph-based IL.  The parallel graph is something you
build out of the IL.  It's the same as with a sequential program, the IL
will tell you that

        if (cond)
           then-clause
        else
           else-clause

is an IL node representing an IF statement.  It's not represented as a
graph, the compiler builds a graph that models the flow of control for
the IF statement.  Same thing with a parallel section:

        cobegin
           T1: { body }
           T2: { body }
        coend

That's all the compiler needs to know.  Out of that cobegin/coend
representation we can now build a PFG (parallel flowgraph).  If the
compiler recognizes synchronization primitives inside the thread bodies,
it can deal with them by adding concurrency edges to the PFG.


Diego.