Re: [Gomp-discuss] [Fwd: [Open64-devel] Announcement of an OpenMP package for ORC1.1/2.0]

[Steven Bosscher]

Pop Sébastian wrote:

> 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.
I think lexing/parsing is not the hard part (in fact it should be the 
easy part); it is how we represent what we parse, and how we transport 
that information though the parser and the optimizers/expanders.  I had 
hoped to see how they do that.

> 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;}
>  
Hmm per-statement expanding??

> 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
Ah, so it does indeed do per-stmt expanding, they don't have cpplib, 
etc...  That is a real shame; makes it pretty much useless to us.

> I like the source code comments :-)  /*ÏÂÃæÑéÖ¤ÊÇ·ñopenmp¹Ø¼ü×Ö*/
Hmm very useful indeed.  I know a few chineese people, maybe they can 
help translating this if you want :-)

> 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.

We are running out of tree nodes real fast.  Obj-C++ is already 
impossible at present without increasing the total possible number of 
tree codes (max 256 now: 8 bit wide bitfield; there's some gross 
duplication in c-common.def and tree.def though, with all that _STMT vs. 
_EXPR nonsense).  So we're going to have to come up with a really sparse 
set of tree types and a number of convincing arguments to show people 
that OpenMP is just as important as (for example) Obj-C++.

Gr.
Steven