[mlir] parseProperties not usable when hasCustomAssemblyFormat

[peledins-zimperium]

setPropertiesFromParsedAttr is generated only when hasCustomAssemblyFormat=0. parseProperties calls ConcreteOpType::setPropertiesFromParsedAttr, so in that case setPropertiesFromParsedAttr needs to be written by hand or worked around it.

setPropertiesFromParsedAttr only sets properties that are not generated elsewhere, so as it stands it would not be useful for the custom assembly format. However, in such case it could be provided with ellided properties attribute.

[llvmbot]

@llvm/issue-subscribers-mlir

Author: None (peledins-zimperium)

`setPropertiesFromParsedAttr` is generated only when `hasCustomAssemblyFormat=0`. `parseProperties` calls `ConcreteOpType::setPropertiesFromParsedAttr`, so in that case `setPropertiesFromParsedAttr` needs to be written by hand or worked around it.

setPropertiesFromParsedAttr only sets properties that are not generated elsewhere, so as it stands it would not be useful for the custom assembly format. However, in such case it could be provided with ellided properties attribute.

[joker-eph]

I'm a bit lost in the description, could you provide a patch demonstrating the problem?

[peledins-zimperium]

Say I have an op with several optional properties:

def MyOp : Op<...>
{
       let hasCustomAssemblyFormat = 1;
       let arguments = (ins OptionalProp<I32Prop> myprop1, ...);
}

Since I have custom format, I have to implement MyOp::parse and MyOp::print.

I would still like to read and write prop-dict, reading it through parseProperties.
However, parseProperties will try to call setPropertiesFromParsedAttr, which is not generated because of custom format.
I think that setPropertiesFromParsedAttr should always be generated in some form, probably by taking additional parameter of ellidedProps.
If that function is not available, then I have to implement the parsing by hand.

[joker-eph]

Thanks for elaborating, I gave it a try here: #145973