[dynamo] Support copy.deepcopy via polyfill

[anijain2305]

Stack from ghstack (oldest at bottom):

• -> [dynamo] Support copy.deepcopy via polyfill #179611

cc @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @kadeng @chauhang @amjames @Lucaskabela @jataylo @azahed98

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/179611

• 📄 Preview Python docs built from this PR
• 📄 Preview C++ docs built from this PR
• ❓ Need help or want to give feedback on the CI? Visit the bot commands wiki

Note: Links to docs will display an error until the docs builds have been completed.

❗ 1 Active SEVs

There are 1 currently active SEVs. If your PR is affected, please view them below:

• Rolling out OSDC (ARC) runners on pull workflow for PyTorch trunk commits

❌ 1 New Failure, 6 Unrelated Failures

As of commit 592c15f with merge base d57eed8 ():

NEW FAILURE - The following job has failed:

• pull / linux-docs / build-docs-python-false (gh)
  'Build python docs'

FLAKY - The following job failed but was likely due to flakiness present on trunk:

• inductor / inductor-test / test (inductor_torchbench, 2, 2, linux.g5.4xlarge.nvidia.gpu) (gh) (similar failure)
  speech_transformer

UNSTABLE - The following jobs are marked as unstable, possibly due to flakiness on trunk:

• trunk / linux-jammy-rocm-py3.10-mi355 / test (default, 2, 6, linux.rocm.gpu.gfx950.1, unstable) (gh) (#179911)
  test/higher_order_ops/test_inline_asm_elementwise.py::TestInlineAsmElementwise::test_correctness_add_fp16_native
• trunk / linux-jammy-rocm-py3.10-mi355 / test (default, 4, 6, linux.rocm.gpu.gfx950.1, unstable) (gh) (#179911)
  test/test_cuda_expandable_segments.py::TestCudaAllocator::test_uuid_visible_devices
• trunk / linux-jammy-rocm-py3.10-mi355 / test (default, 5, 6, linux.rocm.gpu.gfx950.1, unstable) (gh) (#179911)
  test/test_cuda.py::TestCudaAllocator::test_uuid_visible_devices
• trunk / linux-jammy-rocm-py3.10-mi355 / test (default, 6, 6, linux.rocm.gpu.gfx950.1, unstable) (gh) (#179911)
  test/inductor/test_lookup_table.py::TestLookupTableE2E::test_valid_lookup_table_entry_operation_addmm
• trunk / linux-jammy-rocm-py3.10-mi355 / test (distributed, 3, 3, linux.rocm.gpu.gfx950.2, unstable) (gh) (#178884)
  'Test'

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[pytorch-bot]

This PR needs a release notes: label

If your changes are user facing and intended to be a part of release notes, please use a label starting with release notes:.

If not, please add the topic: not user facing label.

To add a label, you can comment to pytorchbot, for example
@pytorchbot label "topic: not user facing"

For more information, see
https://github.com/pytorch/pytorch/wiki/PyTorch-AutoLabel-Bot#why-categorize-for-release-notes-and-how-does-it-work.

[Lucaskabela]

@claude think through the implications and edge cases of the change in guarding behavior:

       if not hasattr(value, "__self__") or isinstance(
                value.__self__, types.ModuleType
            ):
                install_guard(source.make_guard(GuardBuilder.BUILTIN_MATCH))

Are there unintended functions this might result skipping guarding that we need to guard on for correctness?

[claude]

Claude finished @Lucaskabela's task in 6m 18s —— View job

---

• Read the changed code in variables/builder.py and surrounding context
• Understand the BUILTIN_MATCH guard semantics
• Analyze what functions have __self__ that is NOT a types.ModuleType
• Evaluate edge cases and correctness implications
• Post analysis

Analysis of the BUILTIN_MATCH guard change

The change in question (variables/functions.py:2143-2151):

elif inspect.isbuiltin(value):
    if not hasattr(value, "__self__") or isinstance(
        value.__self__, types.ModuleType
    ):
        install_guard(source.make_guard(GuardBuilder.BUILTIN_MATCH))

BUILTIN_MATCH is an id()-based guard (id_match_unchecked at guards.py:2720). The change skips this guard when hasattr(value, "__self__") and not isinstance(value.__self__, types.ModuleType) — i.e., for bound builtin methods on non-module instances.

Why the guard was problematic

The reasoning is sound: bound builtin methods (e.g., obj.__reduce_ex__, obj.__hash__, obj.__sizeof__) are created as fresh Python objects on every attribute access in CPython. Their id() is unstable across compile-time vs. runtime, so an id-based guard would immediately fail and trigger recompilation. This is the same fundamental issue that exists for GetSetDescriptor (line 1471-1478) and MethodWrapper (line 1479-1484) types, which also skip guards for the same reason.

What functions are affected

The guard is now skipped for any builtin where __self__ is not a module. This includes:

Category	Examples	Risk
Dunder methods on user objects	obj.__reduce_ex__, obj.__hash__, obj.__sizeof__, obj.__repr__	Low — these come from object and won't change
Dunder methods on C extension instances	tensor.__reduce_ex__, dict_instance.__reduce_ex__	Low — bound to the type, not mutable
Methods on C types where __self__ is the type	tuple.__new__ (but this is caught by BuiltinMethodVariable first at line 1428)	N/A — doesn't reach this path
Module-level builtins	math.sqrt, os.getpid	Still guarded — __self__ is a ModuleType

What guards remain

When the BUILTIN_MATCH guard is skipped, the comment says "the type guard on the owner object is sufficient." Let me trace through what this means concretely:

For a bound method accessed via obj.attr, the source is typically an AttrSource(obj_source, "attr"). The base object (obj) already has its own guards installed (e.g., TYPE_MATCH or ID_MATCH depending on how the object was built). If the type of the owner object hasn't changed, the method resolution order guarantees the same builtin method will be found.

Edge cases and potential concerns

1. User class overriding a C builtin dunder — This is the most interesting case. Consider:

class Foo:
    pass

class Bar:
    def __reduce_ex__(self, protocol):
        return (Bar, ())

If we first trace with Foo() (gets object.__reduce_ex__, a C builtin), and then call with Bar() (has a Python __reduce_ex__), would we incorrectly skip the guard?

No — the TYPE_MATCH guard on the owner object would catch this. Foo and Bar are different types, so the guard on the base object would invalidate.

2. Monkey-patching __reduce_ex__ on a class after compilation:

class Foo:
    pass

# First call — object.__reduce_ex__ is a C builtin
compiled_fn(Foo())

# Now monkey-patch
Foo.__reduce_ex__ = custom_reduce_ex

# Second call — should recompile, but we skipped BUILTIN_MATCH
compiled_fn(Foo())

This is a real concern. If the source for the bound builtin is something like AttrSource(LocalSource("x"), "__reduce_ex__"), and the only guard is TYPE_MATCH on x, then monkey-patching Foo.__reduce_ex__ would NOT invalidate the type guard (the type is still Foo). The missing BUILTIN_MATCH/ID_MATCH guard means dynamo wouldn't detect that the method changed.

However, in practice this scenario is unlikely to hit because:

• For UserDefinedObjectVariable.var_getattr, __reduce_ex__ is intercepted at line 2022 and returns a UserMethodVariable wrapping the polyfill — it never reaches SkipFunctionVariable.create_with_source at all.
• The SkipFunctionVariable.create_with_source path is only reached when the bound builtin goes through VariableBuilder directly (e.g., a local variable holding a bound method).

3. Bound builtins on non-user-defined objects:

Consider some_random_c_extension_obj.__some_method__. If this C method is a builtin and the object is tracked, skipping the id-based guard relies entirely on whatever guard is on the base object. For most traced objects, TYPE_MATCH is present, which is sufficient.

4. Broader question — is this change too broad?

The change applies to all builtins reaching SkipFunctionVariable.create_with_source, not just __reduce_ex__. While the motivation is copy.deepcopy, any bound C builtin on a non-module instance that somehow reaches this code path would now lack the id-based guard.

In practice, this code path is narrow: it requires a bound C builtin to be loaded as a standalone value (not through call_method dispatch), fail the BuiltinMethodVariable.is_supported_builtin_method check, and go through is_function_or_wrapper → trace_rules.lookup → SkipFunctionVariable. The most common examples are dunder methods accessed via getattr(obj, "__reduce_ex__") or similar patterns.

Recommendation

The change is likely correct for the intended use case but could be tightened:

1. Consider guarding on the method name instead: Rather than dropping the guard entirely, you could install a lighter guard that checks the attribute name resolves to the same underlying function (e.g., via CLOSURE_MATCH on the unbound function, or a HASATTR guard). This would catch monkey-patching.

2. Alternatively, scope it more narrowly: Instead of blanket-skipping for all bound builtins, only skip for specific known-safe methods like __reduce_ex__, __hash__, __sizeof__, etc. That said, the existing approach mirrors what's already done for GetSetDescriptorType and MethodWrapperType (both skip guards entirely), so there's precedent.

3. The monkey-patching gap is a pre-existing issue: The same problem exists for GetSetDescriptorType and MethodWrapperType (lines 1471-1484), which also skip all guards. This PR is following established patterns.

Overall, the correctness risk is low because: (a) the TYPE_MATCH guard on the owner object catches the most common invalidation scenarios (different types), and (b) the specific flow for copy.deepcopy intercepts __reduce_ex__ at the var_getattr level before this code path is even reached for user-defined objects. The main gap (monkey-patching a C builtin dunder on an existing class) is a narrow scenario that's unlikely in practice and consistent with existing guard-skipping patterns in the codebase.

---

[Lucaskabela]

Reading through some of the edge cases I am convinced this approach should be correct, with monkeypatching being a known issue we don't need to bend over for.

[anijain2305]

@pytorchbot merge

[pytorchmergebot]

Merge started

Your change will be merged once all checks pass (ETA 0-4 Hours).

Learn more about merging in the wiki.

Questions? Feedback? Please reach out to the PyTorch DevX Team

Advanced Debugging

Check the merge workflow status
here

[anijain2305]

@pytorchbot merge

[pytorchmergebot]

Merge failed

Reason: New commits were pushed while merging. Please rerun the merge command.

Details for Dev Infra team

Raised by workflow job

[pytorchmergebot]

The merge job was canceled or timed out. This most often happen if two merge requests were issued for the same PR, or if merge job was waiting for more than 6 hours for tests to finish. In later case, please do not hesitate to reissue the merge command
For more information see pytorch-bot wiki.

[pytorchmergebot]

Merge started

Your change will be merged once all checks pass (ETA 0-4 Hours).

Learn more about merging in the wiki.

Questions? Feedback? Please reach out to the PyTorch DevX Team

Advanced Debugging

Check the merge workflow status
here

[pytorchmergebot]

Merge failed

Reason: 1 jobs have failed, first few of them are: trunk / win-vs2022-cuda12.8-py3 / build

Details for Dev Infra team

Raised by workflow job

[anijain2305]

@pytorchbot merge -i

[pytorchmergebot]

Merge started

Your change will be merged while ignoring the following 3 checks: pull / linux-docs / build-docs-python-false, trunk / win-vs2022-cuda12.8-py3 / build, trunk / win-vs2022-cpu-py3 / build

Learn more about merging in the wiki.

Questions? Feedback? Please reach out to the PyTorch DevX Team

Advanced Debugging

Check the merge workflow status
here

[pytorchmergebot]

Merge failed

Reason: 1 jobs have failed, first few of them are: inductor / inductor-test / test (inductor_huggingface, 1, 1, linux.g5.4xlarge.nvidia.gpu)

Details for Dev Infra team

Raised by workflow job

[anijain2305]

@pytorchbot merge

[pytorchmergebot]

Merge started

Your change will be merged once all checks pass (ETA 0-4 Hours).

Learn more about merging in the wiki.

Questions? Feedback? Please reach out to the PyTorch DevX Team

Advanced Debugging

Check the merge workflow status
here

[pytorchmergebot]

Merge failed

Reason: 1 mandatory check(s) failed. The first few are:

• pull / linux-docs / build-docs-python-false

Dig deeper by viewing the failures on hud

Details for Dev Infra team

Raised by workflow job

Failing merge rule: Core Maintainers

[anijain2305]

@pytorchbot merge -i

[pytorchmergebot]

Merge started

Your change will be merged while ignoring the following 7 checks: pull / linux-docs / build-docs-python-false, inductor / inductor-test / test (inductor_torchbench, 2, 2, linux.g5.4xlarge.nvidia.gpu), trunk / linux-jammy-rocm-py3.10-mi355 / test (default, 2, 6, linux.rocm.gpu.gfx950.1, unstable), trunk / linux-jammy-rocm-py3.10-mi355 / test (default, 6, 6, linux.rocm.gpu.gfx950.1, unstable), trunk / linux-jammy-rocm-py3.10-mi355 / test (default, 4, 6, linux.rocm.gpu.gfx950.1, unstable), trunk / linux-jammy-rocm-py3.10-mi355 / test (default, 5, 6, linux.rocm.gpu.gfx950.1, unstable), trunk / linux-jammy-rocm-py3.10-mi355 / test (distributed, 3, 3, linux.rocm.gpu.gfx950.2, unstable)

Learn more about merging in the wiki.

Questions? Feedback? Please reach out to the PyTorch DevX Team

Advanced Debugging

Check the merge workflow status
here