gomp-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Biagio Lucini
Subject: Re: [Gomp-discuss] CIL representation ...
Date: Wed, 12 Mar 2003 15:09:28 +0000 (GMT)

On Wed, 12 Mar 2003, Lars Segerlund wrote:

>
> > At the moment we miss all the code for doing anything. Some time ago, I
> > was proposing to simulate (1) and (2) with some script (Perl, Python,
> > Ruby, whatever the interested people are more familiar with). I think that
> > just trying to implement a design you realise what is wrong with it, so I
> > bring forward again that proposal.
> >
>
>   Now this is a good proposal, however perhaps we can use C and the
> GENERIC definitions fron the gcc source three ? and code the algorithms
> for operations on the tree in C, ( im order to be reused later), while
> doing the framework, ( frontend, and backend ( probably only dumping of
> pseudo code/trees ) in any of the suggested languages.
>
>   I do think that perhaps we could prototype some actions without
> thinking about GENERIC, now to the really great question, which
> scripting language ?
>
>   I would like to have some tk available, so I would propose perl or
> tcl, but I don't know what you people are familiar with ?

Between the two, I would choose (as far as my familiarity is concerned)
perl. So the idea would be:
a) write a pseudo-frontend. This should glance the source code,
count the parallel regions (we leave out the loops for the moment) and
for each variables and each thread decide whether a variable is shared,
local or irrelevant (though I see a bit of optimisation going on
here...) for that parallel region
b) output a file in whatever form (possibly a format reusable by the
middle end) where for each parallel region a thread structure is build
for each thread (by thread structure I mean a structure made of variables
with their private/shared attribute, the code to be executed by this
thread, a pointer to the serial code that will be executed *after* the
thread). This should be suitable (once we understand synchronisation) for
building the corresponding tree structure.

Biagio




reply via email to

[Prev in Thread] Current Thread [Next in Thread]