Add helper for specializing parametric functions

[lsrcz]

This pull request adds a helper for specializing a parametric function with a given environment. The resulting function will be inserted back to the source module.

The C API exposed a "batched" specializing helper that takes an typechecked module and return a cloned typechecked module with all specialized functions inserted. This is needed as our current use of C APIs is assuming that a module is immutable.

[proppy]

could this potentially also be used to add a flag to ir_converter_main that specialize a parametric function?

[lsrcz]

could this potentially also be used to add a flag to ir_converter_main that specialize a parametric function?

@proppy yeah, are you thinking about using a parametric function as the top function, and specialize with some parameters?

[lsrcz]

This PR is now blocked by #3061 as the test suite is referring to functions defined there

[proppy]

@proppy yeah, are you thinking about using a parametric function as the top function, and specialize with some parameters?

👍 yes, this can easily be done w/ a wrapper function today, but is cumbersome to do w/o code generation when you want to instanciate a lot of function variants w/ different sizes.

/cc @richmckeever

[proppy]

This PR is now blocked by #3061 as the test suite is referring to functions defined there

Understood! Let's get #3061 in first.

[lsrcz]

👍 yes, this can easily be done w/ a wrapper function today, but is cumbersome to do w/o code generation when you want to instanciate a lot of function variants w/ different sizes.

Yeah. I used to do code generation to serve my purpose, but replacing all the invocation sites is hard to do without a programmatic way to manipulate the DSLX.

[ericastor]

@richmckeever Any chance you'll be able to take a look soon?

[mikex-oss]

@lsrcz looks like this PR needs to be rebased to resolve merge conflicts. I see an error for the new cc_library added in #3061.

[lsrcz]

@mikex-oss Has just resolved the conflict. Please have a look. Thanks!

[proppy]

re-approving on behalf of @dplassgit

[proppy]

this fails internal checks w/:

xls/dslx/frontend/function_specializer_test.cc:299
TypecheckModule(std::move(cloned_module), module_path.string(), tc_import_data.get()) returned error: INTERNAL: XLS_RET_CHECK failure (xls/dslx/type_system_v2/inference_table.cc:1062) span_filename == module.fs_path()->generic_string() (<specialization:invocation_test:select_poly_34@> vs. invocation_test.x) MakeTypeCheckedNumber span filename must match module fs_path; module name: `invocation_test`; span: `<specialization:invocation_test:select_poly_34@0x5234ffeb63a8>:12:1-15:2`; module fs_path: `invocation_test.x`
=== Source Location Trace: ===
xls/common/status/status_builder.cc:197
xls/dslx/type_system_v2/inference_table.cc:1062
xls/dslx/type_system_v2/inference_table_converter_impl.cc:1756
xls/dslx/type_system_v2/inference_table_converter_impl.cc:720
xls/dslx/type_system_v2/inference_table_converter_impl.cc:241
xls/dslx/parse_and_typecheck.cc:153
xls/dslx/frontend/function_specializer_test.cc:299

[proppy]

@lsrcz can you rebase?

[proppy]

We need to rebase and handle conflict in order to be able to import this.

[lsrcz]

Hi @proppy, I have just rebased the PR and resolved the conflicts. Please take a look. Thank you!