Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
This is my first pass at a custom parser and pretty printer but I had a couple of questions:
- Is it necessary to pass and parse the type for each data variable? I couldn't find any other way of finding out what the type of that argument is at the right time, even though the variable hasn't changed types between the two uses.
- Is there a better way of doing position-independent keywords than my above while loop? I feel like that code is messier than it needs to be.
@DavidTruby I have a few questions/comments.
mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp | ||
---|---|---|
113 | would stringswitch make any difference? | |
121 | Is there no map from keyword to segment number? | |
138–142 | Would having a wrapper for this common pattern make any sense? ParseResult parseOpenMPClause(parser,segment,operand,operandtype) | |
183 | should we have negative tests? | |
188 | Can this be along with the parsing code inside the loop? |
mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp | ||
---|---|---|
113 | As I understand it StringSwitch only works for cases that return a single value, rather than having arbitrary code in each case, so we can't use it here. | |
138–142 | Since we need to return early on failure I'm not sure this is that easy to abstract. I could try it though. | |
188 | The parsing code inside the loop is trying to be position independent (so that the keywords can appear in any order), but the parameters do need to be in the correct order. I believe the only way to ensure that is to add them in the right order down here. |
mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp | ||
---|---|---|
47 | Please avoid trivial braces in MLIR in general. | |
116 | In general we just return failure when calling into the parser fails, because it already emits an error. e.g. : https://github.com/llvm/llvm-project/blob/master/mlir/lib/Dialect/StandardOps/IR/Ops.cpp#L288 | |
mlir/test/Dialect/OpenMP/ops.mlir | ||
108 | This seems a bit light on CHECK lines? |
mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp | ||
---|---|---|
25 | This should go with the first include section. I suspect the "inc" is here because it depends on the other includes. |
mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp | ||
---|---|---|
121 | Agreed. Maybe: keywords ={"if", "...", ...} ... idx = 0 if (keyword == keywords[idx++]) { ... } Or even more structure, e.g., we create these through tablegen ;) (Nit: segments is used as bool array, correct?) |
mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp | ||
---|---|---|
121 | Segments isn't a bool array, it's an array of argument segment sizes that is needed for passing of variadic arguments in MLIR. In the case of if and num_threads the value will always be 0 or 1 (as there can only be one argument passed), but in the case of private/firstprivate/shared/copyin the value will be the number of arguments passed to that clause. |
mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp | ||
---|---|---|
42 | Please add documentation to this function and the functions below. We usually have some variant of EBNF describing what a parsing function accepts. | |
76 | MLIR mostly uses unsigned in such cases | |
124 | Nit: let's not hardcode more than necessary, the operation name can be fetched as result.name.getStrRef() and cached somewhere. | |
128 | Nit: I'd consider named constants for positions in the segment, e.g. segments[kIfClausePos]. | |
237 | Nit: do we really need {}? |
LGTM after clang-format and addressing Mehdi's comment about #include order
mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp | ||
---|---|---|
25 | Please fix. |
This should go with the first include section. I suspect the "inc" is here because it depends on the other includes.