tt-torch

tt-torch is a PyTorch2.0 and torch-mlir based front-end for tt-mlir.

tt-torch uses venv to keep track of all dependencies. After compiling you can activate the venv by running from the project root directory:

source env/activate

The currently supported models can be found here. There is a brief demo showing how to use the compiler in demos/resnet/resnet50_demo.py

The general compile flow is:

1. Pytorch model -> torch.compile which creates an fx graph
2. Several compiler passes on the fx graph including consteval and dead code removal
3. Conversion to torch-mlir -> torch-backend-mlir -> stableHLO through torch-mlir
4. Conversion to TTIR -> TTNN -> flatbuffer through tt-mlir
5. Creating executor with flatbuffer and passing back to user
6. Copying inputs to device and executing flatbuffer through tt-mlir on each user invocation

In order to speed up model bring-up, users have the option of compiling models op-by-op. This allows in-parallel testing of the model since compilation does not stop at the first error. If enabled, see Controlling Compilation, after step 2, compilation stops and the fx graph is passed to the executor which is returned to the user. Upon execution, whenever a new, unique op is seen (based on op-type and shape on inputs), a new fx graph is created with just one operation, inputs and outputs. This small graph then proceeds through steps 3-4 and is executed in place.

Results of each unique op execution are stored in a json file to be later parsed into either a spreadsheet, or uploaded to a database.

Op-by-op execution is currently performed on the pytorch fx graph, we'll be adding support for op-by-op on the stableHLO graph soon to allow op-by-op bringup of onnx models.

The repository uses pre-commit, read more about it here.

Getting Started

System Dependencies

tt-torch requires the python 3.10 dev package, as well as the venv package. If not already installed, please run the following:

sudo apt-get install python3.10-dev python3.10-venv

Creating a Virtual Environment (skip if you already have one)

Create a virtual environment if you do not already have one in your project:

python3.10 -m venv myvenv

This will create a virtual environemnt in the folder myvenv in the current directory.

Activate the environemnt:

source myvenv/bin/activate

Installing tt-torch

Installation Notes

• tt-torch requires a pytorch installation that ships with their ABI.
  • The tt-torch wheel lists the following version of torch as an installation requirement: torch@https://download.pytorch.org/whl/cpu-cxx11-abi/torch-2.5.0%2Bcpu.cxx11.abi-cp310-cp310-linux_x86_64.whl
  • This will be installed by pip upon installing the tt-torch wheel
• The tt-torch wheel contains a fork of torch-mlir. Please ensure that torch-mlir has not been installed in your venv before installing the tt-torch wheel.

Torchvision Install (Required if you need to install torchvision)

If you intend to use torchvision in your project then this step must be done before installing the tt-torch wheel

You will need to build the torchvision wheel yourself with certain build flags. This is because torchvision does not publish a wheel which uses the PyTorch CXX11 ABI.

To install torchvision:

git clone https://github.com/pytorch/vision.git
cd vision
git checkout v0.20.0 # tt-torch requires PyTorch 2.5.0. torchvision 0.20 is the latest version of torchvision that is compatible with PyTorch 2.5.0
pip uninstall -y torchvision # Ensure torchvision is not in your virtual environment
pip install wheel
pip install torch@https://download.pytorch.org/whl/cpu-cxx11-abi/torch-2.5.0%2Bcpu.cxx11.abi-cp310-cp310-linux_x86_64.whl
TORCHVISION_USE_VIDEO_CODEC=0 TORCHVISION_USE_FFMPEG=0 _GLIBCXX_USE_CXX11_ABI=1 USE_CUDA=OFF python setup.py bdist_wheel
pip install dist/torchvision*.whl --force-reinstall

If the install was successful then there's no need to keep the torchvision source around:

cd ..
rm -rf vision

Installing the tt-torch wheel

Download a tt-torch wheel from here

Install the wheel:

pip install <PATH_TO_TT_TORCH_WHEEL>.whl

Updating PYTHONPATH

In addition to the tt-torch python library that gets installed in <YOUR_ENV_ROOT>/lib/python3.x/site-packages, some binaries will be installed in <YOUR_ENV_ROOT>/lib, and some files from tt-metal will be installed under <YOUR_ENV_ROOT>/tt-metal. Python needs to see these installations and so you should update your PYTHONPATH environment variable to include them:

export PYTHONPATH=$PYTHONPATH:<YOUR_ENV_ROOT>:<YOUR_ENV_ROOT>/lib

Compiling and Running a Model

Once you have your torch.nn.Module compile the model:

from tt_torch.dynamo.backend import backend
import torch

class MyModel(torch.nn.Module):
    def __init__(self):
        ...

    def foward(self, ...):
        ...

model = MyModel()

model = torch.compile(model, backend=backend)

inputs = ...

outputs = model(inputs)

Example - Add Two Tensors

Here is an exampe of a small model which adds its inputs running through tt-torch. Try it out!

from tt_torch.dynamo.backend import backend
import torch

class AddTensors(torch.nn.Module):
  def forward(self, x, y):
    return x + y


model = AddTensors()
tt_model = torch.compile(model, backend=backend)

x = torch.ones(5, 5)
y = torch.ones(5, 5)
print(tt_model(x, y))

Prerequisites:

Main project dependencies are:

• clang 17
• Ninja
• CMake >= 3.30
• python 3.10

On Ubuntu 22.04 systems these can be installed using the following commands:

# Update package list
sudo apt update -y
sudo apt upgrade -y

# Install Clang
sudo apt install clang-17

# Install Ninja
sudo apt install ninja-build

# Install CMake
sudo apt remove cmake -y
pip3 install cmake --upgrade

Ensure cmake can by found in this path pip installed it to. E.g. by adding PATH=$PATH:$HOME/.local/bin to your .bashrc file, and verify installation:

cmake --version

This project requires the GCC 11 toolchain. To check which GCC toolchain is currently in use, run:

clang -v

Look for the line that starts with: Selected GCC installation:. If it is something other than GCC 11, please uninstall that and install GCC 11 using:

sudo apt-get install gcc-11 lib32stdc++-11-dev lib32gcc-11-dev

The project also requires a toolchain build. By default, the toolchain is built in /opt/ttmlir-toolchain. This path is controlled by the TTMLIR_TOOLCHAIN_DIR environment variable.

The toolchain installation only needs to be done once, by running the following commands:

# Create toolchain dir
sudo mkdir -p /opt/ttmlir-toolchain
sudo chown -R $USER /opt/ttmlir-toolchain


# Build environment
cd third_party
export TTMLIR_TOOLCHAIN_DIR=/opt/ttmlir-toolchain/
cmake -B toolchain -DBUILD_TOOLCHAIN=ON
cd -

For more information see tt-mlir build steps.

Compile Steps:

Run the following commands to compile. Profiling builds require an extra step¹:

source env/activate
cmake -G Ninja -B build
cmake --build build
cmake --install build

Run a basic test to verify:

pytest tests/torch/test_basic.py

tt-torch uses pytest for all unit and model tests.

Tests are organized into unit tests for pytorch (tests/torch), unit tests for onnx (test/onns) and models (tests/models). They can be run locally by running:

source env/activate
pytest -svv tests/torch

Model tests (tests/models) have the option to run op-by-op, see overview. This allows for faster model bring-up as it allows users to find any potential issues in parallel. This is controlled by the --op_by_op_torch or --op_by_op_stablehlo flags. Example:

pytest -svv tests/models/albert --op_by_op_torch

Controlling Compiler Behaviour

You can use the following environment variables to override default behaviour:

Controlling Compiler Behaviour Programatically

Instead of using the above environment variables, compiler behaviour can be configured programatically as well.

Here is an example of enabling consteval:

from tt_torch.dynamo.backend import backend, BackendOptions
from tt_torch.tools.utils import CompilerConfig
import torch

class MyModel(torch.nn.Module):
    def __init__(self):
        ...

    def foward(self, ...):
        ...

model = MyModel()

cc = CompilerConfig()
cc.enable_consteval = True
cc.consteval_parameters = True # This will enable constant folding on the parameters in addition to any constants

options = BackendOptions()
options.compiler_config = cc
model = torch.compile(model, backend=backend, options=options)

inputs = ...

outputs = model(inputs)

Pre-Commit

Pre-Commit applies a Git hook to the local repository, ensuring linting is checked and applied on every git commit action. Install it from the root of the repository using:

source env/activate
pre-commit install

If you have already made commits before installing the pre-commit hooks, you can run the following to “catch up”:

pre-commit run --all-files

For more information visit pre-commit

Profiling

Introduction

tt-torch uses the tt-metal Tracy fork to collect profiling data. Tracy is a single process profiler, and uses a client-server model to trace both host calls and on-device operation performance. tt-torch implements a wrapper called profile.py with custom orchestration logic to handle the spawning of the Tracy capture server and the client workload to be profiled, as well as report generation and data postprocessing functionality.

The output of profile.py is a CSV report displaying a table of operations executed on device and rich timing, memory usage and configuration data associated with them.

Note: Paths in this document are given relative to the repo root.

Prerequisites

In the tt-torch building step (Building), it is required to configure your cmake build with the additional cmake directive TT_RUNTIME_ENABLE_PERF_TRACE=ON (i.e. run: cmake -G Ninja -B build -DTT_RUNTIME_ENABLE_PERF_TRACE=ON).

Usage

The profile.py tool is the recommended entrypoint for profiling workloads in tt-torch.

profile.py [-h] [-o OUTPUT_PATH] [-p PORT] "test_command"

Note: The test_command must be quoted!

As a minimal example, the following command will run and profile the MNIST test:

python tt_torch/tools/profile.py "pytest -svv tests/models/mnist/test_mnist.py::test_mnist_train[full-eval]"

The report is created at results/perf/device_ops_perf_trace.csv by default, unless an output path is specified.

Limitations

• Tracy is a single process profiler and will not work with multiprocessed workflows. This includes tests parameterized by op_by_op_shlo and op_by_op_torch, which break down a model into individual ops and run them serially in separate processes.
• To view traces, you can use install/tt-metal/generated/profiler/.logs/tracy_profile_log_host.tracy.
  • This is a .tracy file that can be consumed by the tt-metal Tracy GUI and produce visual profiling traces of host and device activity.
  • You must use the tt-metal Tracy GUI to view this file. Refer to the GUI section in the tt-metal profiling documentation. Other sections are not applicable to tt-torch profiling.

Troubleshooting

• tt-torch/install/tt-metal/tools/profiler/bin/capture-release -o tracy_profile_log_host.tracy -f -p 8086' timed out after X seconds
  • Tracy uses a client-server model to communicate profiling data between the Tracy capture server and the client being profiled.
  • Communication between client and server is done on a given port (default: 8086) as specified with the -p option.
  • If there are multiple tracy clients/server processes active at once or previous processes are left dangling, or other processes on host occupying port 8086, there may be contention and unexpected behaviour including capture server timeouts.
  • This may be addressed by manually specifying an unused port with the -p option to profile.py.

How to add model tests?

Requirements

Build your environment

TT-Torch Backend in a nutshell

ModelTester and OnnxModelTester

Our testing framework uses ModelTester, OnnxModelTester defined under tests/utils.py ModelTester and OnnxModelTester are designed to facilitate the testing of PyTorch and ONNX models, respectively. These classes provide a structured framework for loading models, preparing inputs, running inference, and verifying the accuracy of the outputs.

ModelTester

The ModelTester class serves as a base class for testing PyTorch models. It handles common testing procedures and provides abstract methods that derived classes can implement for specific model loading and input preparation. Derived classes must implement the following abstract methods:

• _load_model(): This method should load the PyTorch model to be tested and return the model object.
• _load_inputs(): This method should load or generate the input data for the model and return it. The input should be a Torch object.
• _extract_outputs() (optional): This method should return a tuple of torch tensors based on the outputs if ModelTester _extract_outputs fails.

OnnxModelTester

The OnnxModelTester class inherits from ModelTester and extends it to specifically handle testing of ONNX models.

Derived classes must implement the following abstract methods:

• _load_model(): This method should load the Onnx model to be tested and return the model object.
• _load_inputs(): This method should load or generate the input data for the model and return it. The input should be a Torch object.
• _extract_outputs() (optional): This method should return a tuple of torch tensors based on the outputs if ModelTester _extract_outputs fails.

Backend

Backends are described under tt_torch/dynamo/backend.py and tt_torch/onnx_compile/onnx_compile.py There are a few factors determining which backend to use:

class CompileDepth(Enum):
    TORCH_FX = 1
    STABLEHLO = 2
    TTNN_IR = 3
    COMPILE_OP_BY_OP = 4
    EXECUTE_OP_BY_OP = 5
    EXECUTE = 6

class OpByOpBackend(Enum):
    TORCH = 1
    STABLEHLO = 2

Backends for Torch Models:

• Op by Op Flows (COMPILE_OP_BY_OP/ EXECUTE_OP_BY_OP):
  • OpByOpBackend = TORCH --> uses TorchExecutor
  • OpByOpBackend = STABLEHLO --> uses StablehloExecutor
• Other Compile Depths:
  • Only OpByOpBackend = TORCH is allowed.
  • Uses Executor

Backends for ONNX Models:

• Op by Op Flows (COMPILE_OP_BY_OP/ EXECUTE_OP_BY_OP): Only OpByOpBackend = STABLEHLO is allowed. Uses StablehloExecutor
• Other Compile Depths: Only OpByOpBackend = STABLEHLO is allowed. Uses OnnxExecutor

Executor

TT-Torch provides a set of executor classes that handle different types of models (ONNX, PyTorch) and compilation strategies (full compilation, op-by-op, etc.). The executor classes form a hierarchy, with specialized executors for different scenarios.

Executor (Base)
├── OpByOpExecutor
│   ├── TorchExecutor
│   └── StablehloExecutor
└── OnnxExecutor

• Executor, OnnxExecutor and OpByOpExecutor are defined under tt_torch/dynamo/executor.py
• TorchExecutor is defined under tt_torch/dynamo/torch_backend.py
• StablehloExecutor is defined under tt_torch/dynamo/shlo_backend.py

Executor (Base Class)

The Executor class is the foundation for all executor implementations. It provides the basic framework for:

• Managing model representations (PyTorch programs, etc.)
• Converting input types between different formats
• Handling constants and model parameters
• Executing compiled models via TT-MLIR
• Managing device resources
• Verifying execution results

Key methods:

• __call__: Main entry point for executing the model
• set_binary: Sets the compiled binary for execution
• typecast_inputs: Converts inputs to hardware-supported types
• register_intermediate_callback: Sets up callbacks for runtime verification

OpByOpExecutor

OpByOpExecutor extends the base Executor to support operation-by-operation compilation and execution. This allows for:

• Detailed profiling of individual operations
• Verification of each operation's outputs
• Debugging specific operations that might fail

Key methods:

• compile_op: Compiles a single operation
• run_op: Executes a single compiled operation

TorchExecutor

TorchExecutor is specialized for handling PyTorch models in an op-by-op fashion. It:

• Processes PyTorch FX graph modules node by node
• Converts PyTorch operations to StableHLO
• Compares outputs with golden (PyTorch) outputs for verification

Key methods:

• get_stable_hlo_graph: Converts a PyTorch operation to StableHLO IR
• run_gm_op_by_op: Executes a graph module operation by operation

StablehloExecutor

StablehloExecutor specializes in executing models through the StableHLO IR. It can:

• Process ONNX models converted to StableHLO
• Process PyTorch models converted to StableHLO
• Execute individual StableHLO operations

Key methods:

• add_program: Adds a PyTorch program to the executor
• add_onnx_model_proto: Adds an ONNX model to the executor
• get_stable_hlo_graph: Prepares a StableHLO operation for compilation
• shlo_op_by_op: Executes StableHLO operations individually

OnnxExecutor

OnnxExecutor is designed for handling ONNX models. It can:

• Execute ONNX models using ONNX Runtime
• Execute ONNX models converted to TT-MLIR binaries

CompilerConfig

This class manages settings for running models on Tenstorrent devices. Key aspects include:

• Compilation Depth: Defines the level of the compilation pipeline to reach.
• Profiling: Enables the collection of performance data for individual operations.
• Verification: Controls various checks and validations during compilation.
• Environment Overrides: Allows configuration through environment variables. This is explained in detail under Controlling Compiler Behaviour

Please see tt_torch/tools/utils.py for detailed information.

How to write a test?

The following is an example test body:

# Insert SPDX licensing. Pre-commit will insert if it is missing
# SPDX-FileCopyrightText: (c) 2025 Tenstorrent AI ULC
#
# SPDX-License-Identifier: Apache-2.0

# some base imports that are required for all tests:
import torch
import pytest
import onnx # for Onnx Tests

from tests.utils import ModelTester # for PyTorch Tests
from tests.utils import OnnxModelTester # for Onnx Tests
from tt_torch.tools.utils import CompilerConfig, CompileDepth, OpByOpBackend

class ThisTester(ModelTester): # or class ThisTester(OnnxModelTester):
    def _load_model(self):
        model = ....
        return model
    def _load_inputs(self):
        inputs = ...
        return inputs

# you can pytest parameterize certain arguments. i.e. Mode, OpByOpBackend, Model Name
@pytest.mark.parametrize(
    "mode",
    ["train", "eval"],
)
@pytest.mark.parametrize(
    "model_name",
    [
        "model_name_0",
        "model_name_1",
    ],
)
@pytest.mark.parametrize(
    "op_by_op",
    [OpByOpBackend.STABLEHLO, OpByOpBackend.TORCH, None],
    ids=["op_by_op_stablehlo", "op_by_op_torch", "full"],
)
# For PyTorch Tests
def <test_name>(record_property, model_name, mode, op_by_op):

    cc = CompilerConfig()
    cc.enable_consteval = True
    cc.consteval_parameters = True
    if op_by_op:
        cc.compile_depth = CompileDepth.EXECUTE_OP_BY_OP
        if op_by_op == OpByOpBackend.STABLEHLO:
            cc.op_by_op_backend = OpByOpBackend.STABLEHLO

    tester = ThisTester(
        model_name,
        mode,
        compiler_config=cc,
        record_property_handle=record_property,
    )
    results = tester.test_model()

    if mode == "eval":
        # code to evaluate the output is as expected
    tester.finalize()

# For Onnx Tests:
def <test_name>(record_property, model_name, mode, op_by_op):
    cc = CompilerConfig()
    if op_by_op:
        cc.compile_depth = CompileDepth.EXECUTE_OP_BY_OP
        cc.op_by_op_backend = OpByOpBackend.STABLEHLO

    tester = ThisTester(
        model_name,
        mode,
        compiler_config=cc,
        record_property_handle=record_property,
        model_group="red",
    )

    results = tester.test_model()
    if mode == "eval":
        # code to evaluate the output is as expected
    tester.finalize()

You can find example tests under tests/models Note: please make sure to distinguish Onnx tests by appending _onnx to test names. i.e. test_EfficientNet_onnx.py

Test run modes

• op-by-op flow: This will break down model into graphs and break down graphs into ops, compiling and executing unique (first seen occurrence) ops independently. Results are written to .json file and and optionally converted to XLS file for reporting, as post-processing step. The op-by-op flow is typically used for bringing up new models and debugging and you should start there, especially if the model is a new, untested architecture or your have reason to believe it will not work end-to-end out of the box. Engaged with cc.compile_depth = CompileDepth.EXECUTE_OP_BY_OP in test, typically driven by pytest params [op_by_op_torch-eval].

• full end-to-end flow: This is the typical compile + execute of the model that typically includes functional correctness checking. Engaged with cc.compile_depth = CompileDepth.EXECUTE in test, typically driven by pytest params [full-eval].

Where to add tests on tt-torch GitHub CI?

If you're a Tenstorrent internal developer and have a new model that is either running fully/correctly or still needs some work (compiler support, runtime support, etc), it should be added to CI in the same PR you add the model. Below is guide for where to add it.

Case 1: The new model test runs correctly end-to-end

If you've tried it and it runs – great!

• Add it to run in "nightly full model execute list" in .github/workflows/run-full-model-execution-tests-nightly.yml while ideally balancing existing groups of tests. Example:

tests/models/Qwen/test_qwen2_casual_lm.py::test_qwen2_casual_lm[full-Qwen/Qwen2.5-1.5B-eval]

• Also add it to "weekly op-by-op-flow list" in .github/workflows/run-op-by-op-flow-tests-weekly.yml where we less frequently run tests that have all ops passing through to EXECUTE depth in op-by-op flow. Example:

tests/models/Qwen/test_qwen2_casual_lm.py::test_qwen2_casual_lm[op_by_op_torch-Qwen/Qwen2.5-1.5B-eval]

Case 2: The new model test runs end-to-end but encounters a PCC/ATOL/Checker error

This is okay, there is still value in running the model.

• Follow previous section instructions for adding it to "nightly full model execute" and "weekly op-by-op-flow list" but first open a GitHub issue (follow template and models_pcc_issue label like the example below) to track the PCC/ATOL/Checker error, reference it in the test body so it can be tracked/debugged, and disable PCC/ATOL/Token checking as needed. Example:

# TODO Enable checking - https://github.com/tenstorrent/tt-torch/issues/490
assert_pcc=False,
assert_atol=False,

Case 3: The new model test does not run correctly end-to-end

No problem. If your end-to-end model hits a compiler failure (unsupported op, etc) or runtime assert of any kind, this is why the op-by-op flow exists. The op-by-op flow is designed to flag per-op compile/runtime failures (which are perfectly fine) but is expected to return overall passed status.

• Go ahead and run the op-by-op flow locally (or on CI) for your model, and if the pytest finishes without fatal errors, add it to the "nightly op-by-op flow list" (a new or existing group) in .github/workflows/run-op-by-op-flow-tests-nightly.yml where individual ops will be tracked/debugged and later promoted to "nightly full model execute list" once ready. Example:

tests/models/t5/test_t5.py::test_t5[op_by_op_torch-t5-large-eval]

• It is helpful if you can run python results/parse_op_by_op_results.py (will generate results/models_op_per_op.xlsx for all models you've recently run in op-by-op-flow) and include the XLS file in your PR. This XLS file contains op-by-op-flow results and is also generated in Nightly regression for all work-in-progress models in .github/workflows/run-op-by-op-flow-tests-nightly.yml.

• If your model is reported in results/models_op_per_op.xlsx as being able to compile all ops successfully (ie. all ops can compile to status 6: CONVERTED_TO_TTNN, but some hit runtime 7: EXECUTE failures) then it should also be added to "nightly e2e compile list" in .github/workflows/run-e2e-compile-tests.yml which stops before executing the model via TT_TORCH_COMPILE_DEPTH=TTNN_IR pytest ...

How to load test files into/from Large File System (LFS)

We have set up access to a AWS S3 bucket to be able to load and access model related files for testing. We can load files into our S3 bucket and access them from the tester scripts. You will need access to S3 bucket portal to add files. If you don't have an AWS account or access to the S3 bucket please reach out to the tt-torch community leader. Then, depending on if the test is running on CI or locally we will be able to load the files from the CI/IRD LFS caches that automatically sync up with contents in S3 bucket.

Load files into S3 bucket

Access S3 bucket portal, if you don't have access to the S3 bucket please reach out to the tt-torch community leader, and load file from local dir. Please add files following this structure:

test_files
├── pytorch
|   ├── huggingface
|   |   ├── meta-llama
│   |   |   ├── Llama-3.1-70B
│   |   |   |   └── <hugginface files>
│   |   |   ├── Llama-2-7b-hf
│   |   |   |   └── <hugginface files>
│   |   |   └── ...
│   |   └── ...
│   ├── yolov10
│   |   └── yolov10.pt
│   └── ...
└── onnx
    ├── ViT
    |   └── ViT.onnx
    └── ...

Load files from S3 bucket

Once files is loaded into S3 bucket we can access the file using a helper function:

@staticmethod
def get_file(s3_path):

from tests.utils import ModelTester, get_file, skip_full_eval_test

...
class ThisTester(ModelTester):
    def _load_model(self):
        file = get_file("test_files/pytorch/yoloyv10/yolov_10n.pt")

...

The s3_path arg should be the full path of the file in the S3 bucket.

Loading files locally

Locally get_file() will pull files directly from an IRD LFS cache. The IRD LFS cache is set up to sync up with S3 bucket every 5-10 minutes. You will need to set the IRD_LF_CACHE environment variable to the appropriate address. Contact tt-torch community leader for IRD LF cache address.

The file/s will be downloaded into a local cache so next time you want to access the same file we won't have to access the IRD cache. The default location for the local cache is ~/.cache/. If you want to redirect files to a custom cache path set the LOCAL_LF_CACHE env variable to the desired path.

Loading files from CI

Once a file has been loaded into ther S3 bucket the CI's shared DOCKER_CACHE_DIR has been set up to sync up with the contents of the S3 bucket every hour. get_file() will fetch the file from the DOCKER_CACHE_DIR.

Supported Models

The following models can be currently run through tt-torch as of Feb 3rd, 2025. Please note, there is a known bug causing incorrect output for some models. The PCC is displayed at the end of each test below. This issue will be addressed soon.

Ops Documentation

This section contains documentation for Ops operations.

Stablehlo Documentation

This section contains documentation for Stablehlo operations.

arith.constant

stablehlo.add::ttnn.add

stablehlo.and::ttnn.and

stablehlo.broadcast_in_dim