[BACKEND] Add Tsingmicro backend integration (Triton 3.6)

[tsingmicro-public-e]

Summary

Add the Tsingmicro backend integration based on Triton 3.6.

Changes

• Add third_party/tsingmicro/ backend: compiler/driver, Tx81 CRuntime, MLIR conversion
  passes, and the tsingmicro-opt tool.
• Add TLE-Struct DSA support: tle.language.dsa primitives, the tle-dsa dialect
  (DsaDialect, DsaToCore conversion) and its pybind (triton_tle_dsa.cc).
• Register dsa.* primitives in TLE_PRIMITIVES and add
  third_party/tsingmicro/backend/tle_supported.py for the TLE primitive whitelist.
• Add dsa integration tests under python/test/tle/integration/.

[CLAassistant]

All committers have signed the CLA.

[sunnycase]

Hi @tsingmicro-public-e, thank you for contributing the Tsingmicro backend integration.

Could you please update the PR description with implementation and evaluation details similar to PR #843, including:

• A complete list or status table of the TLE primitives implemented and supported by this backend, including the new tle.language.dsa primitives.
• Known limitations, constraints, and currently unsupported TLE primitives or features.
• Performance data for representative workloads, with comparison baselines where available. Please also include the relevant hardware, software, input shapes, and benchmark configuration so that the results are reproducible.

This information would help reviewers assess the current feature coverage, usability, and performance of the backend. Thank you!

[sunnycase]

cumsum should be a tle-lite primitive.

[sunnycase]

extract/insert_tile should be tle-lite primitives.

[sunnycase]

One more suggestion: for this PR, could you please place randgen, rand, and randn under tle.dsa.tsingmicro for now? We would like to further evaluate whether these primitives are sufficiently generic across backends. If they prove to be broadly applicable, we can consider moving them to tle-lite in a follow-up.

[tsingmicro-public-e]

One more suggestion: for this PR, could you please place randgen, rand, and randn under tle.dsa.tsingmicro for now? We would like to further evaluate whether these primitives are sufficiently generic across backends. If they prove to be broadly applicable, we can consider moving them to tle-lite in a follow-up.

Hi @sunnycase, thank you for the review and the suggestion!

Just to make sure we implement it correctly: when you say placing randgen/rand/randn under tle.dsa.tsingmicro, do you mean:

1. A real namespace change — users would call them as tle.dsa.tsingmicro.randgen(...) (similar to tle.dsa.ascend.UB on Ascend), and tle.dsa.randgen would be removed; or
2. Only a code-organization change — the implementations move into a separate tsingmicro module for easier maintenance, but the public API remains tle.dsa.randgen(...).

We are assuming (1), since it matches the existing dsa.ascend pattern, but we'd like to confirm before refactoring. Thank you!