I come into a problem that the following code generates different results in different files:
mlir::TypeID id = mlir::TypeAttr::getTypeID();
fprintf(stderr,"hash = %zu\n", mlir::hash_value(id));
However, the results are consistent when MLIR is statically linked. I noticed this comment in the function that generates TypeID:
I want to ask whether this is an already-known problem and how should I work around. Currently I want to cast an Attribute to TypeAttr and I get an empty result because the TypeID is inconsistent.
It seems that the main executable and libMLIR.so, these two binaries both contain the static variables defined in TypeID.h, and they are actually stored seperately. I guess it might be sometimes unsafe to use static variable to generate unique id.
Yes, if you were explicitly hiding symbols (i.e. with a glob) in your linker script, it would have this problem across shared library boundaries that both use this MLIR facility. I’m not aware of a way out of it aside from exactly what you did (add an exception to not hide these symbols). The standard answer of building with hidden visibility by default, done right, will entail quite a bit of work across LLVM/MLIR, and I’m not aware of any effort in that direction.