cc_xls_ir_jit_wrapper fails to resolve entrypoints w/ name conflicts

[proppy]

Describe the bug

When attempting to use cc_xls_ir_jit_wrapper w/ https://github.com/google/xls/tree/main/xls/examples/matmul_4x4, the toolchain currently fails to resolve the block IR entrypoint w/ the following error:

More than one instance with name: __matmul_4x4__matmul_4x4_0_next

This seems to be due the block IR containing a proc and block w/ the same name:

functions: [],  procs: [__matmul_4x4__matmul_4x4_0_next, __matmul_4x4__matmul_4x4__matmul_0__node_0_next, __matmul_4x4__matmul_4x4__matmul_0__node_1_next, __matmul_4x4__matmul_4x4__matmul_0__node_2_next, __matmul_4x4__matmul_4x4__matmul_0__node_3_next, __matmul_4x4__matmul_4x4__matmul_0__node_4_next, __matmul_4x4__matmul_4x4__matmul_0__node_5_next, __matmul_4x4__matmul_4x4__matmul_0__node_6_next, __matmul_4x4__matmul_4x4__matmul_0__node_7_next, __matmul_4x4__matmul_4x4__matmul_0__node_8_next, __matmul_4x4__matmul_4x4__matmul_0__node_9_next, __matmul_4x4__matmul_4x4__matmul_0__node_10_next, __matmul_4x4__matmul_4x4__matmul_0__node_11_next, __matmul_4x4__matmul_4x4__matmul_0__node_12_next, __matmul_4x4__matmul_4x4__matmul_0__node_13_next, __matmul_4x4__matmul_4x4__matmul_0__node_14_next, __matmul_4x4__matmul_4x4__matmul_0__node_15_next, __matmul_4x4__matmul_4x4__matmul_0__4_4_next], blocks: [__matmul_4x4__matmul_4x4_0_next]

Expected behavior

Since cc_xls_ir_jit_wrapper also includes a mandatory wrapper_type attr, it should be able to disambiguish and resolve the right entrypoint.

[proppy]

Looking at

xls/xls/jit/aot_compiler_main.cc

Lines 60 to 80 in 3a71d29

	ABSL_FLAG(std::string, input, "", "Path to the IR to compile.");
	ABSL_FLAG(std::optional<std::string>, top, std::nullopt,
	"IR function to compile. "
	"If unspecified, the package top function will be used - "
	"in that case, the package-scoping mangling will be removed.");
	ABSL_FLAG(std::optional<std::string>, output_object, std::nullopt,
	"Path at which to write the output object file.");
	ABSL_FLAG(std::optional<std::string>, output_proto, std::nullopt,
	"Path at which to write the AotPackageEntrypointsProto describing "
	"the ABI of the generated object files.");
	ABSL_FLAG(std::optional<std::string>, output_textproto, std::nullopt,
	"Path to write a textproto AotPackageEntrypointsProto describing the "
	"ABI of the generated object file.");
	ABSL_FLAG(std::optional<std::string>, output_llvm_ir, std::nullopt,
	"Path at which to write the output llvm file.");
	ABSL_FLAG(std::optional<std::string>, output_llvm_opt_ir, std::nullopt,
	"Path at which to write the output optimized llvm file.");
	ABSL_FLAG(std::optional<std::string>, output_asm, std::nullopt,
	"Path at which to write the output optimized llvm file.");
	ABSL_FLAG(int64_t, llvm_opt_level, xls::LlvmCompiler::kDefaultOptLevel,
	"The optimization level to use for the LLVM optimizer.");

it seems that wrapper_type is not passed to the AOT compiler and that it only relies on the name being associated w/ a single symbol:

xls/xls/jit/aot_compiler_main.cc

Lines 258 to 259 in 3a71d29

	XLS_ASSIGN_OR_RETURN(f, package->GetFunctionBaseByName(
	absl::StrCat(package_prefix, *top)));

before resolving the type of the entrypoint:

xls/xls/jit/aot_compiler_main.cc

Line 264 in 3a71d29

if (f->IsFunction()) {