[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gomp-discuss] [Fwd: [Open64-devel] Announcement of an OpenMP packag
From: |
Pop Sébastian |
Subject: |
Re: [Gomp-discuss] [Fwd: [Open64-devel] Announcement of an OpenMP package for ORC1.1/2.0] |
Date: |
Mon, 9 Jun 2003 14:14:29 +0200 |
User-agent: |
Mutt/1.4i |
On Mon, Jun 09, 2003 at 12:05:21PM +0200, Steven Bosscher wrote:
> I assume you've asked for c-parse.y on their mailing list or something?
>
I think that the c-parse.y won't be of much help in our case, since our
c++ parser is no longer written using yacc, and the c will be rewritten as
well.
Now that I have analyzed a little the patch, here is a short sketch:
they slightly modified the lexer to recognise the openMP specific tokens,
then they modified the parser adding constructs like:
+case 355:
+#line 1787 "c-parse.y"
+{ yyval.pclause_type = build_parallel_clause_if(yyvsp[-1].ttype); ;
+ break;}
Each clause is added to a list of clauses with functions like:
struct parallel_clause_list *
chain_parallel_list_on (struct parallel_clause_list * pclause_list, struct
parallel_clause_list * pclause)
Then, once all the clauses have been collected, they build the omp pragma WHIRL
nodes
based on the lists of clauses:
+case 349:
+#line 1763 "c-parse.y"
+{
+ expand_start_parallel(yyvsp[0].pclause_type);
+ free(yyvsp[0].pclause_type);
+ ;
+ break;}
void expand_start_parallel (struct parallel_clause_list * clause_list)
that calls the WHIRL emitter:
void WFE_expand_start_parallel (struct Parallel_clause_wn_type
*parallel_clause_wn)
{
...
wn = WN_CreatePragma(WN_PRAGMA_PARALLEL_BEGIN,
(ST_IDX) NULL,
0,
0);
...
}
Other notes:
The parser and lexer are based on gcc-2.95.3, and thus they are quite different
from
what we have to play with... For example, the lexer has been modified when the
new
preprocessor has been included in gcc-3.0
I like the source code comments :-) /*ÏÂÃæÑéÖ¤ÊÇ·ñopenmp¹Ø¼ü×Ö*/
I don't know how good is their diagnostic system (ie. warnings emitted when a
pragma
is ill formed, ...) since this is encoded in the grammar file c-parse.y
It is possible to catch the main idea that we could follow in our
implementation:
- add new token types to the lexer,
- add new rules to the parser that will emit new tree types,
- lower the GOMP_TREE_NODEs at an appropriate level.