Skip to content

fix(dynamo): handle dynamic (ITensor) negative start in impl.slice.sl… - #4486

Open
apbose wants to merge 1 commit into
mainfrom
abose/slice_op_dynamic_negative_start
Open

fix(dynamo): handle dynamic (ITensor) negative start in impl.slice.sl…#4486
apbose wants to merge 1 commit into
mainfrom
abose/slice_op_dynamic_negative_start

Conversation

@apbose

@apbose apbose commented Aug 13, 2026

Copy link
Copy Markdown
Collaborator

Fixes #4186

@meta-cla meta-cla Bot added the cla signed label Aug 13, 2026
@github-actions github-actions Bot added component: tests Issues re: Tests component: conversion Issues re: Conversion stage component: core Issues re: The core compiler component: converters Issues re: Specific op converters component: api [Python] Issues re: Python API component: dynamo Issues relating to the `torch.compile` or `torch._dynamo.export` paths labels Aug 13, 2026
@github-actions
github-actions Bot requested a review from narendasan August 13, 2026 21:39
…ice_op

slice_op's negative-index wraparound (start -> start + dim_size) only
fired for a literal Python int start known at trace time. When start is a
TRTTensor instead - a value computed at conversion time by some other
converter's own implementation code, not something that can come from the
FX graph itself - its sign isn't known until the engine runs, so the
wraparound was silently skipped and the raw (possibly negative) value was
fed straight to ISliceLayer, which TensorRT rejects as an out-of-bounds
start.

No currently-registered converter passes a TRTTensor start (aten_ops_slice,
set_item, and embedding.py's slice_op call sites all use literal ints), so
this has no effect on any shipped converter today. It matters for
converter authors: slice_op is a public, reusable impl-layer helper (see
tutorials/extensibility/converters), and the reporter hit this while
building a converter of their own that computes its start dynamically,
resorting to a hand-rolled workaround because the wraparound wasn't
generic.

A model-level regression test isn't possible here: torch.export resolves
the sign of a slice bound via guards at trace time rather than carrying it
as a truly runtime-only-known value. E.g.

    class M(torch.nn.Module):
        def forward(self, x):
            return x[-(x.shape[0] // 2):]

    torch.export.export(
        M(), (x,),
        dynamic_shapes={"x": {0: torch.export.Dim("n", min=2, max=64)}},
    )

raises ConstraintViolationError ("Not all values of n ... satisfy the
generated guard (-1)*(x.size()[0] // 2) < 0 ...") - export refuses to
generalize the trace across the declared dynamic range once the sign
isn't fixed for every value in it. So this case can never reach slice_op
through torch_tensorrt.compile() with a compiled torch.nn.Module; it is
only reachable by calling impl.slice.slice_op directly, the same way a
converter author would. The added test (TestSliceOpDynamicStart) does
exactly that: it builds a small TensorRT network by hand and calls
slice_op with a start TRTTensor whose value (-2) is only computed at
runtime, verifying the build fails before this fix and produces the
correct wrapped-around result after it.

Fixes #4186
@apbose
apbose force-pushed the abose/slice_op_dynamic_negative_start branch from b76b23f to 9c57a30 Compare August 13, 2026 21:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cla signed component: api [Python] Issues re: Python API component: conversion Issues re: Conversion stage component: converters Issues re: Specific op converters component: core Issues re: The core compiler component: dynamo Issues relating to the `torch.compile` or `torch._dynamo.export` paths component: tests Issues re: Tests

Projects

None yet

Development

Successfully merging this pull request may close these issues.

🐛 [Bug] slice_op not able to handle start value with type trt.ITensor

1 participant