|
From: | Steven Bosscher |
Subject: | Re: [Gomp-discuss] [Fwd: [Open64-devel] Announcement of an OpenMP package for ORC1.1/2.0] |
Date: | Mon, 09 Jun 2003 14:34:34 +0200 |
User-agent: | Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3.1) Gecko/20030425 |
Pop Sébastian wrote:
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.On Mon, Jun 09, 2003 at 12:05:21PM +0200, Steven Bosscher wrote: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 assume you've asked for c-parse.y on their mailing list or something?
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??
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.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
Hmm very useful indeed. I know a few chineese people, maybe they can help translating this if you want :-)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.
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
[Prev in Thread] | Current Thread | [Next in Thread] |