metagraph-dev / pymlir Goto Github PK

We currently lose the visibility attribute of "private" when round tripping MLIR input text through PyMLIR in this example:

>>> import mlir
>>> input_string = "func private @resize_pointers(!llvm.ptr<i8>, index, index) -> ()"
>>> mlir.parse_string(input_string).body[0].dump()
'func @resize_pointers(!llvm.ptr< i8 >, index, index) {\n}'
>>> 

import mlir

mlir_text = r"""

func @bad_func() -> tensor<8xf32> {
  %0 = constant dense<0.0> : tensor<8xf32> : tensor<8xf32> 
  return %0 : tensor<8xf32>
}

"""

print(mlir_text)

mlir.parse_string(mlir_text)

This should not parse. It does parse.

Ideally, %0 = constant dense<0.0> : tensor<8xf32> : tensor<8xf32> would cause an exception to be raised.

Proximal cause:

• This is the rule for dense_elements_attribute. It requires a colon+type.
• dense_elements_attribute is a sub-rule of elements_attribute.
• elements_attribute is a sub-rule of standard_attribute.
• standard_attribute is a sub-rule of attribute_value .
• attribute_value is used in the constant op of the standard dialect, which additionally requires a type to be written (which means 2 type declarations in total, which causes the bug).

Perhaps having this parse is a non-issue since one could argue that it might be syntactically valid (which I'm not sure I agree with) but is semantically invalid.

Here's an algorithm to generate tons of tests:

• For each dialect file found here:
  • For each DialectOp in the dialect file:
    • For each use of a rule from mlir.lark in the DialectOp:
      • Recursively go down the tree for the mlir.lark rule and generate as many examples as possible.
      • See if these examples are accepted by mlir-opt with no passes specified.

This will require an intractable amount of work, so it might not be motivated until MLIR is more stable, but it might be motivated in the future as I suspect the rules in mlir.lark are not as robust or correct as we need it to be.

This might have helped us discover #7 earlier. I suspect that there are similar problems with how standard_attribute is currently defined (either with how it's defined or with how it's used in the dialects currently).

The MLIR docs provide rules for their syntax (e.g. here), and as far as I can tell by my cursory look, these rules describe a context-free language, so using the CFG approach taken so far via lark should in theory work. Perhaps just going down the syntax rules as listed in the MLIR docs could work as a better first step to make sure we have sufficient test coverage of things that should be accepted before we start testing things that should be not accepted.