[LLVMdev] [cfe-dev] OpenMP support in CLANG: A proposal
Eli Friedman
eli.friedman at gmail.com
Tue Oct 16 18:30:29 PDT 2012
On Tue, Oct 16, 2012 at 4:11 AM, Mahesha HS <mahesha.llvm at gmail.com> wrote:
> Hi Eli,
>
> Attached is the next patch in the line. This patch
> (class_pragma_omp_handler_support.patch) contains the implementation
> of the class "class PragmaOmpHandler". I also attached the test case
> (openmp_syntax_test.c). This test case is actually to test the
> syntactically legal simple OpenMP constructs. However, we can *really*
> test it only after submitting the next two patches - one related to
> PragmaOmpHandler object construction and the another related to OpenMP
> parsing.
>
> Please, let me know, if you need to know any additional information.
>
> If you think that some other mechanism is required to speed-up the
> review process, I will really welcome it.
At this point, it's just a matter of finding time to review it.
+ // \Brief: Holds all the OpenMP clause name strings.
+ // \Brief: These strings are referenced while parsing OpenMP clauses.
+ // Note that we won't introduce new *tokens* for openMP clause names
+ // as these will get conflict with *identifier* token, and is very tricky
+ // to handle. Instead, we reference below strings to recognize the OpenMP
+ // clause names.
+ StringRef* Clause[END_CLAUSE];
This isn't correct documentation comment syntax; clang trunk has a
warning -Wdocumentation to catch this.
It's almost never appropriate to construct a StringRef*; a StringRef
is already essentially a pointer.
Is this array even necessary? It's not clear what you're using it
for. If you want to convert from the enum to a string, just implement
a method like "static StringRef StringForDefaultKind(ClauseKind
Kind);" or something like that.
+ // Note: These enum values *must* be in consistant in *size* and *order* with
+ // that of enum values defined in the AST node class "OmpClause".
If you want to share an enum, put it into a header in
include/clang/Basic/. (A new header if no existing one is
appropriate.) Having the same enum in multiple places is asking for
trouble.
This patch has a lot of copy-paste code; can you write a single
PragmaHandler subclass which is parameterized based on the pragma in
question? (Or maybe a few, since it looks like some of them need
special handling which is not yet implemented?)
It looks like the only members of PragmaOmpHandler which actually need
to be in a header are PragmaOmpUnknownWarning, initialize method, and
the enums; please move PragmaOmpUnknownWarning and initialize onto the
Preprocessor class, the enums into a new header in
include/clang/Basic/, and everything else into the .cpp file, and
remove include/clang/Lex/PragmaOmpHandler.h.
-Eli
More information about the llvm-dev
mailing list