Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Arm/TOSA: allow int64 through when the spec declares the int64 extension

Offen
  • Stimmt etwas nicht?
#24,095 4 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

@abm-77 arbeitet bereits daran.

Seit 23.10.2026.

  • #24128 von @abm-77 — offen

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
54/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
python, pytorch
Bereich
backend, machine-learning

Rechercherichtung

Start by reading backends/arm/tosa/mapping.py and locating map_dtype, then trace the three int64 cast passes and the node validators and visitor dtype lists named in the issue. Check how each path accesses the TOSA specification and compare lowering under TOSA-1.0+INT and TOSA-1.1+INT+int64. Done means int64 is preserved and serializes with the extension enabled, while the existing int32 casting behavior remains for specs without it.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

bug module: arm partner: arm
🐛 Describe the bug

TosaSpecification accepts TOSA-1.1+INT+int64 and support_extension("int64") returns True, but this is not honored downstream. The Arm backend narrows int64 to int32 anyway, and then refuses to serialize the int64.

Repro, an embedding with an int64 index, lowered under both specs:

import traceback
import torch
from torch.export import export
from torchao.quantization.pt2e.quantize_pt2e import convert_pt2e, prepare_pt2e

from executorch.backends.arm.quantizer.arm_quantizer import (
    TOSAQuantizer, get_symmetric_quantization_config,
)
from executorch.backends.arm.tosa import TosaSpecification
from executorch.backends.arm.tosa.compile_spec import TosaCompileSpec
from executorch.backends.arm.tosa.partitioner import TOSAPartitioner
from executorch.exir import to_edge_transform_and_lower


class Embed(torch.nn.Module):
    def __init__(self):
        super().__init__()
        self.emb = torch.nn.Embedding(10, 3)

    def forward(self, idx):
        return self.emb(idx)


def run(spec_str):
    print(f"=== {spec_str} ===", flush=True)
    inputs = (torch.tensor([[1, 2, 3, 4]], dtype=torch.int64),)
    tosa_spec = TosaSpecification.create_from_string(spec_str)
    print(f"support_extension('int64') = {tosa_spec.support_extension('int64')}")

    quantizer = TOSAQuantizer(tosa_spec)
    quantizer.set_global(get_symmetric_quantization_config())

    prepared = prepare_pt2e(
        export(Embed().eval(), inputs).module(check_guards=False), quantizer
    )
    prepared(*inputs)
    converted = convert_pt2e(prepared)

    try:
        to_edge_transform_and_lower(
            export(converted, inputs),
            partitioner=[TOSAPartitioner(TosaCompileSpec(spec_str))],
        )
        print("lowered OK")
    except Exception:
        traceback.print_exc()


for s in ("TOSA-1.0+INT", "TOSA-1.1+INT+int64"):
    run(s)

Under TOSA-1.0+INT:

support_extension('int64') = False
WARNING insert_int32_casts_after_int64_placeholders: Inserting a casting node
  _to_dim_order_copy_default after idx to cast int64 placeholder to int32 for idx
lowered OK

Under TOSA-1.1+INT+int64:

support_extension('int64') = True
WARNING insert_int32_casts_after_int64_placeholders: Inserting a casting node
  _to_dim_order_copy_default after idx to cast int64 placeholder to int32 for idx
  File "executorch/backends/arm/tosa/mapping.py", line 98, in map_dtype
    raise ValueError(f"Unsupported type: {data_type}")
ValueError: Unsupported type: torch.int64

The above exception was the direct cause of the following exception:

File "executorch/backends/arm/process_node.py", line 188, in process_inputs
ValueError: Failed processing input placeholder: idx. Is the original torch function supported?

InsertInt32CastsAfterInt64PlaceholdersPass is constructed without a spec. It therefore cannot tell whether int64 is allowed, and rewrites the placeholder before serialization runs. Under TOSA-1.0+INT
that is intended and lowering succeeds. The model still ends up computing in 32 bits, with only a log warning.

UNSUPPORTED_DTYPES in backends/arm/tosa/mapping.py is a module-level tuple that lists torch.int64. map_dtype's only argument is a dtype, so there is no spec available to check against. TOSA 1.1 added
the int64 extension after this code was written.

Proposed changes:

  1. map_dtype to take the spec and allow int64 when the spec declares the extension.
  2. InsertInt32CastsAfterInt64PlaceholdersPass, ConvertInt64ConstOpsToInt32Pass and ConvertInt64OutputOpsToInt32Pass to skip on the same condition.
  3. Node validators and the per-visitor dtype lists to accept int64 on the same condition.

Related: #12957 proposes sharing the int64 cast pass across backends, on the basis that the TOSA backend requires int32 inputs. That assumption does not hold with the int64 extension enabled. A
shared pass would need the same spec check.

Happy to put up PRs if this approach sounds right.

Versions
Versions
  PyTorch version: 2.14.0+cu130
  OS: Rocky Linux 9.8 (Blue Onyx) (x86_64)
  GCC version: (GCC) 11.5.0 20240719 (Red Hat 11.5.0-14)
  Libc version: glibc-2.34
  Python version: 3.11.13 (64-bit runtime)
  Python platform: Linux-5.14.0-611.54.1.el9_7.x86_64-x86_64-with-glibc2.34

  Versions of relevant libraries:
  [pip3] executorch==1.5.1
  [pip3] numpy==2.1.3
  [pip3] pytorch_tokenizers==1.5.0
  [pip3] torch==2.14.0
  [pip3] torchao==0.18.0

cc @digantdesai @freddan80 @per @zingo @oscarandersson8218 @mansnils @Sebastian-Larsson @robell @rascani

Vorherrschende Sprache
Python
Sterne
5.1k
Forks
1.2k
Ø Merge
1 T. 22 Std.
Gemergte PRs (30 T.)
684

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus pytorch/executorch

Alle Issues in pytorch/executorch

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.