gomp-discuss
[Top][All Lists]
Advanced

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

[Gomp-discuss] Parsing tree's and so on ..


From: Lars Segerlund
Subject: [Gomp-discuss] Parsing tree's and so on ..
Date: Wed, 05 Feb 2003 11:04:25 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9


 Hi, I have some thought's that have emerged.

Steven Bosher wrote:
>I really don't like the idea of making this whole thing too
>OMP-specific.  OpenMP may not be around for ever, but concurrency
>probably will be around for a while. Also, the whole infrastructure in
>the middle end that we're talking about now has the potential to be >much
>bigger than OpenMP itself (autoparallelization? MPI-code? Who knows...)
>
>I would prefer some generic names like FOR_EACH (or PARALLEL_FOR, or
>FORALL, DOALL, whatever), BARIER, SECTION, etc.  OK the names I just
>typed down are still very OpenMP, but I guess you get the idea: Have
>tree nodes that express explicit concurrency and translate OpenMP to
>those tree nodes.

Here is why I wanted the distributed and parallell distinction for the sections, if we ever wanted to do HPF or compiled APL this would come in handy ! Also I'm all for reducing the set of 'primitives' we need, and it might not be that tough, the basic primitives are parallell sections, all the DO and FOR loops are just variations on this, furthermore, the interesting bit would be PRIVATE, SHARED variables and BARRIER, SYNC and an ATOMIC attribute. I.e. most of the other constructs can be rewritten into prarallell sections.

As for the parsing of the pragmas, I have thought that we should handle this in the middle end ? This since we have a representation to check for the nessesary requirements at this point, I think it would be excruchinctly hard to do at the parse level.

Steven's last suggestion however seems to be the best of all worlds, and something I think we can do along with.

Steven Bosher wrote:
>Why not make the parser generate an explicitly concurrent AST, and make
>the middle-end ignore them until they're actually implemented?

In other words, in contrary to my earlier opinion, I am all for handling the omp directives in the parse phase and emitting a tree with parallell information further.

 I think  Steven is onto the 'pudel's kern'.

 / regards, Lars Segerlund.





reply via email to

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