[flang-commits] [mlir] [flang] [mlir] Expose type and attribute names in the MLIRContext and abstract type/attr classes (PR #72189)

Fehr Mathieu via flang-commits flang-commits at lists.llvm.org
Wed Nov 29 19:55:01 PST 2023


math-fehr wrote:

> > So my understanding is that `DenseMap<StringAttr, AbstractType*>` was what was creating the problem, but I'm not sure if this is a mistake on my end or if this is not possible.
> > For it to work, we would need to create a `StringAttr` before loading the `builtin` dialect, is that possible? This is because when we are loading the `builtin` dialect, we need to create those `StringAttr` for the type names when we load each type/attribute.
> 
> Oh great... We can't add the name for `StringAttr` before registering the storage is that it?
> 
> Pretty sad about these string duplication, but we can live with it. Please document this next to the StringMap.
> 
> > So for now I removed it, please tell me if you see a way I could make this work!
> 
> It's likely possible, but will require some deeper look. I may try this after you land it!

Another solution would be to use a `DenseMap` of `StringRef` instead, as all names are basically `StringLiteral` for C++ defined attributes, and `StringRef` for dynamically defined attributes (as they already store their names).
Do you think that makes more sense for this PR?

https://github.com/llvm/llvm-project/pull/72189


More information about the flang-commits mailing list