Commit Graph

7 Commits

Author SHA1 Message Date
Shraiysh Vaishay 5bec1ea7a7 [mlir] Added oilist primitive
This patch attempts to add the `oilist` primitive proposed in the [[ https://llvm.discourse.group/t/rfc-extending-declarative-assembly-format-to-support-order-independent-variadic-segments/4388 | RFC: Extending Declarative Assembly Format to support order-independent variadic segments ]].

This element supports optional order-independent variadic segments for operations. This will allow OpenACC and OpenMP Dialects to have similar and relaxed requirements while encouraging the use of Declarative Assembly Format and avoiding code duplication.

An oilist element parses grammar of the form:
```
clause-list := clause clause-list | empty
clause := `keyword` clause1 | `otherKeyword` clause2
clause1 := <assembly-format element>
clause2 := <assembly-format element>
```

AssemblyFormat specification:
```
let assemblyFormat = [{
  oilist( `keyword` clause1
        | `otherkeyword` clause2
        ...
        )
}];
```

Example:
```
oilist( `private` `(` $arg0 `:` type($arg0) `)`
      | `nowait`
      | `reduction` custom<ReductionClause>($arg1, type($arg1)))

oilist( `private` `=` $arg0 `:` type($arg0)
      | `reduction` `=` $arg1 `:` type($arg1)
      | `firstprivate` `=` $arg3 `:` type($arg2))
```

Reviewed By: Mogball, rriddle

Differential Revision: https://reviews.llvm.org/D115215
2022-02-17 11:10:24 +05:30
Mogball 42f87a0354 [mlir][ods] NFC Fix ASAN error in FormatParser
Some FormatElement subclasses contain `std::vector`. Since these use
BumpPtrAllocator, they need to be converted to trailing objects.
However, this is not a trivial fix so I will leave it as a FIXME and use
a workaround.
2022-02-02 04:29:57 +00:00
Mogball 0bc0ad86e2 [mlir][ods] Unify Attr/TypeDef and Operation Format Parsing
Part 2 of 3 of unifying the assembly formats of attributes/types and operations.The last patch that introduced attribute/type formats (D111594) factored out the format lexer entirely. This patch factors out most of the format parsers such that the attribute/type and op parsers only need to implement handling for specific elements.

Certain things could be factored better (element verification, 'seen' variables) but the primary goal of factoring is so that features can be used across both assembly formats.

Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D117971
2022-02-01 07:28:37 +00:00
River Riddle 6842ec42f6 [mlir][NFC] Add a using for llvm::SMLoc/llvm::SMRange to LLVM.h
These are used pervasively during parsing.

Differential Revision: https://reviews.llvm.org/D118291
2022-01-26 21:37:23 -08:00
Mehdi Amini 63f0c00d38 Add a `qualified` directive to the Op, Attribute, and Type declarative assembly format
This patch introduces a new directive that allow to parse/print attributes and types fully
qualified.
This is a follow-up to ee0908703d which introduces the eliding of the `!dialect.mnemonic` by default and allows to force to fully qualify each type/attribute
individually.

Differential Revision: https://reviews.llvm.org/D116905
2022-01-11 01:30:19 +00:00
Mehdi Amini 48fb79effb Improve error message when declarativeAssembly contains invalid literals
Differential Revision: https://reviews.llvm.org/D115085
2021-12-04 00:27:32 +00:00
Jeff Niu 9a2fdc369d [MLIR] Attribute and type formats in ODS
Declarative attribute and type formats with assembly formats. Define an
`assemblyFormat` field in attribute and type defs with a `mnemonic` to
generate a parser and printer.

```tablegen
def MyAttr : AttrDef<MyDialect, "MyAttr"> {
  let parameters = (ins "int64_t":$count, "AffineMap":$map);
  let mnemonic = "my_attr";
  let assemblyFormat = "`<` $count `,` $map `>`";
}
```

Use `struct` to define a comma-separated list of key-value pairs:

```tablegen
def MyType : TypeDef<MyDialect, "MyType"> {
  let parameters = (ins "int":$one, "int":$two, "int":$three);
  let mnemonic = "my_attr";
  let assemblyFormat = "`<` $three `:` struct($one, $two) `>`";
}
```

Use `struct(*)` to capture all parameters.

Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D111594
2021-11-08 17:38:28 +00:00