jl-generators.cpp changes

[glou-nes]

@jumerckx, sorry for the formatting.

I try to implement features in JuliaLLVM/TableGen.jl#1 in C++
I implement several ideas :

• renaming result_ to result
• apply the typing defining in args, for instance: result_layouts=nothing::Union{Attribute, Nothing} doesn't constraint result_layouts so change to : result_layouts::Union{Attribute, Nothing} =nothing
• create Julia enum for EnumAttr : using Attr parsing (MLIR doesn't expose methods in C to easily construct arbitrary attribute) and discriminant.
• typing Attribute and use Julia type for easy ones (Int, Float, Vector).
• more complex Attributes ("struct" layout) such as conv

[jumerckx]

This is super cool!!!

sorry for the formatting.

My bad, the file should've been properly formatted in the first place 😅.

I've done a quick review and this is clearly a strict improvement over what we had.
I imagine the next step would be to update dialect calls throughout the project? If you want I can try help out with that.

[glou-nes]

This is super cool!!!

sorry for the formatting.

My bad, the file should've been properly formatted in the first place 😅.

I've done a quick review and this is clearly a strict improvement over what we had. I imagine the next step would be to update dialect calls throughout the project? If you want I can try help out with that.

@jumerckx I think so, an other interesting part can be to handle "struct" attr, the C part is not exposed for all dialect, so using parse can be doable here. I try to get rid of parsing and build attribute directly from data with not much success (anyway parse is probably not the heaviest operation atm), Do you have experience with attribute internals? I don't know if we want to do all the attribute change directly or doing enum/simple one firstly and "struct" one after. Do you have ideas here?

[jumerckx]

I try to get rid of parsing and build attribute directly from data with not much success (anyway parse is probably not the heaviest operation atm)

When I wrote the original generator, I asked around on the MLIR discord and the conclusion was that this was impossible using the C API.
I agree using parse seems the way to go for now, the struct stuff looks very cool already!

[glou-nes]

I try to get rid of parsing and build attribute directly from data with not much success (anyway parse is probably not the heaviest operation atm)

When I wrote the original generator, I asked around on the MLIR discord and the conclusion was that this was impossible using the C API. I agree using parse seems the way to go for now, the struct stuff looks very cool already!

Thank for the confirmation, my idea was to add a C API in ReactantExtra to manually create custom attributes. The parsing work for almost all attributes: the few ones left are not specialized and here a generic IR.Attribute must be provided.

[jumerckx]

The parsing work for almost all attributes:

Would a custom CAPI extension help with this? I imagine not but might be misunderstanding.

What happens with attribute values that don't have a corresponding Julia type that can be used in the struct? Does it fallback to ::String fields in the struct then, or is this a case where a generic IR.Attribute has to be provided?

[glou-nes]

The parsing work for almost all attributes:

Would a custom CAPI extension help with this? I imagine not but might be misunderstanding.

What happens with attribute values that don't have a corresponding Julia type that can be used in the struct? Does it fallback to ::String fields in the struct then, or is this a case where a generic IR.Attribute has to be provided?

generic IR.Attribute in this case, an example of that with VHLO_DictionaryAttrV1 and the Parameter : ArrayRefParameter<"std::pair<mlir::Attribute, mlir::Attribute>"> . I suppose it's better to get the generic option, because that kind of parameters have probably custom/complex parsing logic.