Token conflict in parsing optional attributes

MLIR
1

Hi,

I am trying to add optional string attribute to several SPIR-V ops. For example I want the following cases to be valid:

// case 1
spv.selection "Flatten" {
  // region
}

// case 2
spv.selection {
  // region
}

I cannot use assembly format since there is no handling of regions yet, so I was trying to reuse parseOptionalAttribute() method for this purpose.

I noticed that when handling case 2 in the example above, parseOptionalAttribute() parses the region’s brace and tries to handle this as if it would parse a dictionary attribute. Further, this is not only the case of having a region after optional attribute. For any op with the similar form where attr-dict follows the optional

def FormatOptAttrCOp : TEST_Op<"format_opt_attr_op_b"> {
  let arguments = (ins OptionalAttr<I64Attr>:$opt_attr);
  let assemblyFormat = "($opt_attr^)? attr-dict";
}

there are the following results:

// work fine
test.format_opt_attr_op_b
test.format_opt_attr_op_b 10
test.format_opt_attr_op_b 10 {bar}

// error: failed to satisfy constraint: 64-bit signless integer attribute
test.format_opt_attr_op_b {bar}

Of course I can create a separate method that deals specifically with the case I need (optional string before region), but I am wondering if this behaviour is expected at all and whether my approach is correct.

Thanks,

George

2

Hey George, one thing to keep in mind is that the assembly format is entirely up to us to define. Assembly parsing ambiguity can sometimes easily be solved by adjusting the assembly format a bit.

For this specific case, I think we can parse the Flatten as a keyword by using parseOptionalKeyword. Plus we have cleaner assembly without the quote. IIRC we have utility functions for parsing enum keyword attribute in general and they should be largely reusable.