[cfe-dev] OpenMP support in CLANG: A proposal
mahesha.llvm at gmail.com
Wed Nov 7 02:54:53 PST 2012
Here is my further update.
1. As I already mentioned in my previous reply, extra redundant
Handler classes are removed, and we can do magic with just one Handler
2. Later, after shooting my reply to your mail, I started to think
that I can even get rid of extra annotated omp tokens, as you
inidicated. I can achieve similar functionality by keeping *only one*
generic omp token, and *without* lexing the omp directive *name* in
the Handler, instead allowing it to take care by Parser.
3. Regarding your suggestion of *not* disturbing Global Parser and
Sema, I really doubt, if I can avoid it. I agree that, Global Parser
and Sema should not be disturbed to handle the stuffs which is suppose
to be handled by Preprocessor. But, as you already guessed, re-design
for Clang is required to achieve this, and I do not think if it can be
achieved very quickly though it may not be an impossible task.
4. I quickly went through the following link to understand the concept
of C++11 attributes -
this doc, I see some proposal to represent OpenMP directives as C++11
attributes, though I do not know if any other compilers have already
implemented OpenMP by parsing C++11 attribute based OpenMP
representation. I am bit confused here about your suggestion of not
using ASTs to represent OpenMP statements. As per my understanding,
GCC and other compilers create ASTs for OpenMP constructs - and make
use of these ASTs for further *outlining* of parallel OpenMP regions,
and sub-sequent *lowering*. I do have an opinion that ASTs are very
much required to process classic OpenMP *pragma* constructs. However,
I appreciate, if you can share your suggestion with more *detail*
On Wed, Nov 7, 2012 at 8:32 AM, Mahesha HS <mahesha.llvm at gmail.com> wrote:
> On Tue, Nov 6, 2012 at 8:45 PM, Olaf Krzikalla
> <Olaf.Krzikalla at tu-dresden.de> wrote:
>> I did a quick look at your code and have some comments about it:
> Thanks for the review Olaf. Yes, I have re-factored the code to a
> greater extent to simplify the things, and I am still working on
> re-factoring. However, please find my answers to some of your
> questions which are inlined.
>> 1. I don't think it is neccessary to introduce different classes for the
>> various sub-domains. One pragma handler class should do the trick.
> I already re-implemented it exactly as you mentioned. The initial
> thinking of introducing different classes was based on the design
> decision that "Pragma handler" should call appropriate handler based
> on the omp directive name like "#pragma omp parallel", "#pragma omp
> for", etc. So I landed up deriving a separate class for each omp
> pragma directive name, from pragma handler interface. Now, I
> re-implemented it by having only one omp pragma handler class, and
> parsing the omp directive names by making use of appropriate enums and
> string comparison.
>> Also I
>> don't think that you need extra tokens.
> If we handle everything within a Handler it-self, then, tokens may not
> be required. However, OpenMP syntax and semantics is quite involved.
> We have to ask global Parser and Sema to do it. Following are the
> reasons for it.
> 1. OpenMP statements are part of function body statements.
> 2. OpenMP statements contain expression. scope (in case of "if"
> clause) and structured blocks. So, we have to piggy back Global parser
> to handle scopes, parse expressions and compound statement (structured
> block). Moreover, few OpenMP constructs like "barrier" are valid only
> within a structured block (parallel region) which follows omp parallel
> constructs. That means, OpenMP parsing is recursive in nature.
> So we need to have tokens which represent different OpenMP directives
> (note - only for directives not for clauses), and Handler will insert
> those tokens to token streams depending on the type of the omp
> directive. Then, global Parser and Sema will take it forward.
>> The sub-domain is always an
>> identifier. Parse it and schedule based on a string comparision.
> I agree. I am already re-implemented exactly as you mentioned.
>> 2. Do not derive OpenMP directives from Stmt. Literally they are no
>> statements but directives. OpenMP directives attribute the statement
>> following immediately (and I use "attribute" here by full intent - always
>> keep C++11 attributes in mind). If there are also other pragmas before a
>> for-statement you might run in serious trouble. That said, you should try to
>> use (and maybe extend) the already installed attribute framework in the AST.
> I accept. I will re-think about it, and re-implement it. Probably I
> will share the AST design before implementing.
>> 3. I wonder if we need to touch Sema and Parser the way you do. Granted, the
>> Parser needs some extensions (more on that in the next bullet). But the
>> parsing should be done in the handler, since OpenMP is not a part of C/C++
>> but rather an extension.
> As I mentioned above, I do think that global Parser and Sema need to
> be involved in handling of OpenMP stuffs, at least for the time being,
> as per the present Clang design. However, this topic is subjected to
> further discussion.
>> 4. Last and most important point for other people still reading: clang DOES
>> need a way to parse expressions inside of pragmas. Admittedly this violates
>> the separation of concerns since pragmas exist at the preprocessor level and
>> expressions exist at the Sema level. However that's just how it is. I hacked
>> my own solution in Scout but after many hours of bug fixing I won't
>> advertise that solution here. Instead I would opt for a parser redesign so
>> that it is possible to have more than one parser at the same time operating
>> on a token stream. Then we could construct a parser in a pragma handler and
>> just call ParserExpression (or what else needs to be parsed). Thus the state
>> of the global parser is not touched and it will happily jump to eol.
>> Best regards
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
More information about the cfe-dev