eval_module failed when compiling with gcc

[qingyunqu]

What happened?

I found this bug when I try to use stablehlo's interpreter in torch-mlir. It could be reproduced at torch-mlir main branch:

from torch_mlir import ir
from torch_mlir._mlir_libs._stablehlo import eval_module
from torch_mlir._mlir_libs._stablehlo import register_dialect
import numpy as np

module_str = """
module attributes {torch.debug_module_name = "ArgmaxKeepdimModule"} {
  func.func @forward(%arg0: tensor<4x4xf32>, %arg1: tensor<4x4xf32>) -> tensor<4x4xf32> {
    %0 = stablehlo.add %arg0, %arg1 : tensor<4x4xf32>
    return %0 : tensor<4x4xf32>
  }
}
"""

with ir.Context() as context:
    register_dialect(context)
    module = ir.Module.parse(module_str)
    input = ir.DenseElementsAttr.get(np.random.random(size=(4, 4)).astype(np.float32))
    mlir_args = [input, input]
    rets = eval_module(module, mlir_args)
    print(rets)

It will produce error:

ValueError: input args must be DenseElementsAttr

[qingyunqu]

BTW, it passed when compiling torch-mlir with clang.

[qingyunqu]

_stablehlo.cpython-39-x86_64-linux-gnu.so have different *mlir* symbol between gcc and clang

[qingyunqu]

I think it would also get the same failure when building stablehlo by gcc without torch-mlir.

[qingyunqu]

I think previous issue(https://github.com/openxla/stablehlo/issues/2170) catch the same problem.

[GleasonK]

Thanks for raising this issue. Starting to understand the importance of not exposing mlir:: symbols in these APIs -- we plan to fix this up but timeline unknown, top of the refactoring priorities, but below feature development like DotAlgorithms.

We will not be adding any new APIs without proper CAPI shims, recently added register_all_passes with proper shim.