[Codegen][Tuner] verifier for the default tuning spec

[bangtianliu]

This PR adds the unit attribute iree_codegen.tuning_spec_with_default_entrypoint to indicate the default tuning spec (typically or user-provided tuning spec but can work in the same manner) must contain one named sequence operation marked with __kernel_config, also add the corresponding verification in verifyOperationAttribute function.

This PR is relevant to task in #19214: add a discardable attr verifier for entry points iree_codegen.tuning_spec_entrypoint

Context:
Jakub proposed two approaches for verifying the default tuning specification:

1. Implement a dedicated pass for verification.
2. Add a new attribute and update the verifyOperationAttribute function accordingly.

After careful consideration, we agreed on the second approach to avoid introducing an additional pass, ensuring a simple implementation.

[kuhar]

Can you explain what are the alternatives you considered and why you decided on this way of verifying the default specs? IIRC, we first discussed a dedicated verification pass.

Also, please update the documentation in https://iree.dev/reference/tuning/

[kuhar]

There are test failures.

[bangtianliu]

Can you explain what are the alternatives you considered and why you decided on this way of verifying the default specs? IIRC, we first discussed a dedicated verification pass.

Also, please update the documentation in https://iree.dev/reference/tuning/

During our discussion, you proposed two approaches: 1) use one separate pass to verify the default spec; 2) add one attribute and update the verifyOperationAttribute function. At the end, I think we both agree on second one, is my understanding wrong?

[kuhar]

This is something that should be explained in the PR description for all the other folks who did not join the same meeting

[bangtianliu]

This is something that should be explained in the PR description for all the other folks who did not join the same meeting

Ok, will add it in the PR description.

[bangtianliu]

There are test failures.

Yeah, will work on fixing it.

[bangtianliu]

In cases where both a user-provided tuning specification (tuning_spec_mmt_tile_and_fuse.mlir) and the default specification (iree_default_tuning_spec_gfx942.mlir) are used, the default spec part, after linking the two MLIR files, contains a named sequence operation with the symbol name __kernel_config_1 instead of __kernel_config. This behavior is due to the logic implemented here: LinkTuningSpecsPass.cpp, Line 110.

To address this which causes the ci errors, I updated the code from

SymbolTable::getSymbolName(namedSeqOp).getValue() ==
                   kKernelConfigSpecName;

to

SymbolTable::getSymbolName(namedSeqOp)
                  .getValue()
                  .contains(kKernelConfigSpecName);

[kuhar]

contains a named sequence operation with the symbol name __kernel_config_1 instead of __kernel_config. This behavior is due to the logic implemented here: LinkTuningSpecsPass.cpp, Line 110.

Good observation, this needs to be handled.

To address this which causes the ci errors, I updated the code from

This fix is incorrect. It no longer verifies the there's the exact entry point with the default name. If the outermost entrypoint is anything __kernel_config, the tuning spec won't be applied. Instead, we need to drop the module-level attribute whenever we rename entrypoints during linking.

[kuhar]

LGTM