frozenleaves/pytorch
1
0
Fork 0
mirror of https://github.com/pytorch/pytorch.git synced 2025-10-20 12:54:11 +08:00
Code Issues Packages Projects Releases Wiki Activity

Fix xrefs (#151888)

Browse Source 
Fix existing cross references and removed old ones

Pull Request resolved: https://github.com/pytorch/pytorch/pull/151888
Approved by: https://github.com/eqy, https://github.com/huydhn, https://github.com/svekars
This commit is contained in:
Anthony Shoumikhin
2025-04-25 21:27:27 +00:00
committed by PyTorch MergeBot
parent 1aa971a3bb
commit 9e50c21e27
13 changed files with 23 additions and 30 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
CONTRIBUTING.md
View File

@ -281,8 +281,6 @@ dependencies as well as the nightly binaries into the repo directory.
* [caffe2](caffe2) - The Caffe2 library.
* [core](caffe2/core) - Core files of Caffe2, e.g., tensor, workspace,
blobs, etc.
* [operators](caffe2/operators) - Operators of Caffe2.
* [python](caffe2/python) - Python bindings to Caffe2.
* ...
* [.circleci](.circleci) - CircleCI configuration management. [README](.circleci/README.md)

2
aten/src/ATen/cudnn/README.md
View File

@ -1,4 +1,4 @@
All files living in this directory are written with the assumption that cuDNN is available,
which means that these code are not guarded by `#if AT_CUDNN_ENABLED()`. Therefore, whenever
you need to use definitions from here, please guard the `#include<ATen/cudnn/*.h>` and
definition usages with `#if AT_CUDNN_ENABLED()` macro, e.g. [native/cudnn/BatchNorm.cpp](native/cudnn/BatchNorm.cpp).
definition usages with `#if AT_CUDNN_ENABLED()` macro, e.g. [native/cudnn/BatchNorm.cpp](../native/cudnn/BatchNorm.cpp).

2
aten/src/ATen/mkl/README.md
View File

@ -1,4 +1,4 @@
All files living in this directory are written with the assumption that MKL is available,
which means that these code are not guarded by `#if AT_MKL_ENABLED()`. Therefore, whenever
you need to use definitions from here, please guard the `#include<ATen/mkl/*.h>` and
definition usages with `#if AT_MKL_ENABLED()` macro, e.g. [SpectralOps.cpp](native/mkl/SpectralOps.cpp).
definition usages with `#if AT_MKL_ENABLED()` macro, e.g. [SpectralOps.cpp](../native/mkl/SpectralOps.cpp).

4
aten/src/ATen/native/nested/README.md
View File

@ -16,7 +16,7 @@ When constructing a NestedTensor in C++ you will likely not be using the NestedT
## Code Structure
The NestedTensor code is split into two parts: the C++ code and the Python code. The C++ code is located in [aten/src/ATen/native/nested](.) and the Python code is located in [torch/nested/__init__.py](/torch/nested/__init__.py). The C++ code is split into the following files:
The NestedTensor code is split into two parts: the C++ code and the Python code. The C++ code is located in [aten/src/ATen/native/nested](.) and the Python code is located in [torch/nested/__init__.py](../../../../../torch/nested/__init__.py). The C++ code is split into the following files:
- `NestedTensorImpl.h | NestedTensorImpl.cpp`: The NestedTensor data structure and its methods.
- `NestedTensorUtils.h | NestedTensorUtils.cpp`: Utility functions for working with NestedTensors. (This is where you will find `map_nested_tensor` which is discussed below in the section on implementing new functions.)
@ -60,4 +60,4 @@ If performance is not your main concern and you would like to enable coverage th
## Best Practices
## Testing
Unit tests for NestedTensors can be found at [test/test_nestedtensor.py](/test/test_nestedtensor.py). If a new operator is added to NestedTensors it is important to add a unit test for it. The unit tests are run on the CI and if they fail the PR will not be merged.
Unit tests for NestedTensors can be found at [test/test_nestedtensor.py](../../../../../test/test_nestedtensor.py). If a new operator is added to NestedTensors it is important to add a unit test for it. The unit tests are run on the CI and if they fail the PR will not be merged.

7
test/distributed/elastic/test_control_plane.py
View File

@ -57,9 +57,10 @@ class WorkerServerTest(TestCase):
self.assertEqual(resp.status, 200)
self.assertEqual(
resp.data,
b"""<h1>torch.distributed.WorkerServer</h1>
<a href="/handler/">Handler names</a>
""",
b"<h1>torch.distributed.WorkerServer</h1>\n"
b'<a href="'
b"/handler/"
b'">Handler names</a>\n',
)
resp = pool.request("POST", "/handler/ping")

2
test/onnx/torchlib/README.md
View File

@ -36,7 +36,7 @@ Sometimes, there is no existing OpInfo that fits our need to test an operator. Y
Follow the steps below to create new OpInfo tests:
1. Use the implementation for `ops.aten.slice_scatter` as a reference (https://github.com/microsoft/onnxscript/blob/e67335101e4a06b8cc98cb4129935a9af5062c77/tests/function_libs/torch_lib/extra_opinfo.py#L2412-L2418) to declare an OpInfo in [`extra_opinfo.py`](./extra_opinfo.py)
1. Use the implementation for `ops.aten.slice_scatter` as a reference (https://github.com/microsoft/onnxscript/blob/e67335101e4a06b8cc98cb4129935a9af5062c77/tests/function_libs/torch_lib/extra_opinfo.py#L2412-L2418) to declare an `OpInfo` in `extra_opinfo.py`.
```py
opinfo_core.OpInfo(

2
torch/ao/quantization/backend_config/README.md
View File

@ -1,6 +1,6 @@
## BackendConfig Overview
BackendConfig allows PyTorch quantization to work with different backend or kernel libraries. These backends may have different sets of supported quantized operator patterns, and the same operator patterns may require different handling across different backends. To make quantization work with different backends and allow maximum flexibility, we strived to make all the parts of the quantization flow configurable with BackendConfig. Currently, it is only used by FX graph mode quantization. For more details on how it integrates with the FX graph mode quantization flow, refer to this [README](/torch/ao/quantization/fx/README.md).
BackendConfig allows PyTorch quantization to work with different backend or kernel libraries. These backends may have different sets of supported quantized operator patterns, and the same operator patterns may require different handling across different backends. To make quantization work with different backends and allow maximum flexibility, we strived to make all the parts of the quantization flow configurable with BackendConfig. Currently, it is only used by FX graph mode quantization. For more details on how it integrates with the FX graph mode quantization flow, refer to this [README](../fx/README.md).
BackendConfig configures quantization behavior in terms of operator patterns. For each operator pattern, we need to specify what the supported data types are for the input and output activations, weights, and biases, and also specify the QAT modules, the reference quantized modules etc., which will be used in module swapping during the quantization passes.

2
torch/ao/quantization/fx/README.md
View File

@ -446,4 +446,4 @@ However, for some operator based backends, like the current pytorch native backe
## Extensibility
FX graph mode quantization can be extended to work with different backends, which may have different sets of supported quantized operator patterns and different requirements for each pattern. For more detail, please refer to the [BackendConfig README](/torch/ao/quantization/backend_config/README.md).
FX graph mode quantization can be extended to work with different backends, which may have different sets of supported quantized operator patterns and different requirements for each pattern. For more detail, please refer to the [BackendConfig README](../backend_config/README.md).

5
torch/csrc/distributed/c10d/control_plane/WorkerServer.cpp
View File

@ -96,9 +96,8 @@ WorkerServer::WorkerServer(const std::string& hostOrFile, int port) {
"/",
[](const httplib::Request& req [[maybe_unused]], httplib::Response& res) {
res.set_content(
R"BODY(<h1>torch.distributed.WorkerServer</h1>
<a href="/handler/">Handler names</a>
)BODY",
"<h1>torch.distributed.WorkerServer</h1>\n"
"<a href=\"/handler/\">Handler names</a>\n",
"text/html");
});
server_.Get(

15
torch/csrc/jit/OVERVIEW.md
View File

@ -367,7 +367,7 @@ Values are abstract representations of data in the program. When executing, the
## Type ##
[aten/src/ATen/core/jit_type.h](/aten/src/ATen/core/jit_type.h)
[aten/src/ATen/core/jit_type.h](../../../aten/src/ATen/core/jit_type.h)
TorchScript, unlike Python, is statically typed, so every `Value` has a Type associated with it, and every FunctionSchema has a list of argument types and a return type for a function. Type is the base class of a hierarchy of C++ objects that represent the built-in types of TorchScript. Types provide methods such as `Type::isSubtypeOf` that describe the typing relationships. Common type are:
@ -389,7 +389,6 @@ JIT programs are created using either the tracing frontend (`torch.jit.trace`) o
[tracer.h](frontend/tracer.h)
[tracer_state.h](frontend/tracer_state.h)
The tracer produces graphs by recording what actual operations are done on `Tensors`.
The entry point from Python into C++ for tracing using `torch.jit.trace` is `_create_method_from_trace`.
@ -398,7 +397,7 @@ A thread local instance of the TracingState object maintains a mapping between a
An initial `IValue` to `Value` mapping is set up between the inputs to the function being traced and symbolic `Value` inputs to the `Graph` being constructed. If we are tracing a `torch.nn.Module`, the tracer also adds Parameters and sub-Modules to the Module being constructed that correspond to the Python `torch.nn.Module` being traced. Mappings for these values are also added so that uses of the Parameters in the trace will create uses of the Parameters in the `Graph`.
As the trace runs, individual operators create `Nodes` in the `Graph` being traced to record what happens. This code is currently generated per operator in [tools/autograd/gen_variable_type.py](/tools/autograd/gen_variable_type.py). It results in code that looks like the following:
As the trace runs, individual operators create `Nodes` in the `Graph` being traced to record what happens. This code is currently generated per operator in [tools/autograd/gen_variable_type.py](../../../tools/autograd/gen_variable_type.py). It results in code that looks like the following:
```cpp
torch::jit::Node* node = nullptr;
@ -434,7 +433,7 @@ The resulting `Graph` created by tracing is installed as the 'forward' method of
## Script ##
The script frontend directly converts Python syntax into Modules. Like many compilers this happens in two phases. First, we generate an abstract syntax tree (AST), which is constructed out of Tree objects. The IR emitter then does semantic analysis on the Tree and lowers it into a Module. We can generate Trees in two ways: (1) using frontend.py, which takes the Python AST and transliterates it into Tree objects, or (2) via the Lexer and Parser which parse Python syntax directly. The Lexer+Parser path may seem redundant but it is crucially important. We need to define builtin functions ([frontend/builtin_functions.cpp](frontend/builtin_functions.cpp)) when Python is not linked because we allow users to generate TorchScript programs directly from strings containing Python source code ([api/include/torch/jit.h](/torch/csrc/api/include/torch/jit.h)) without linking a full Python implementation (e.g. CPython). We also use this Python syntax as the serialization format for TorchScript, since it allows us to make changes to our IR without breaking backward compatibility. Furthermore, the Lexer is reused to implement the FunctionSchema parser, which turns FunctionSchema declarations from strings into FunctionSchema objects.
The script frontend directly converts Python syntax into Modules. Like many compilers this happens in two phases. First, we generate an abstract syntax tree (AST), which is constructed out of Tree objects. The IR emitter then does semantic analysis on the Tree and lowers it into a Module. We can generate Trees in two ways: (1) using frontend.py, which takes the Python AST and transliterates it into Tree objects, or (2) via the Lexer and Parser which parse Python syntax directly. The Lexer+Parser path may seem redundant but it is crucially important. We need to define builtin functions ([frontend/builtin_functions.cpp](frontend/builtin_functions.cpp)) when Python is not linked because we allow users to generate TorchScript programs directly from strings containing Python source code ([api/include/torch/jit.h](../api/include/torch/jit.h)) without linking a full Python implementation (e.g. CPython). We also use this Python syntax as the serialization format for TorchScript, since it allows us to make changes to our IR without breaking backward compatibility. Furthermore, the Lexer is reused to implement the FunctionSchema parser, which turns FunctionSchema declarations from strings into FunctionSchema objects.
The following sections look into each the stages in the script frontend in detail.
@ -761,7 +760,7 @@ Optimization passes that wish to exploit multi-threaded execution may automatica
## IValue ##
[ivalue.h](/aten/src/ATen/core/ivalue.h)
[ivalue.h](../../../aten/src/ATen/core/ivalue.h)
All evaluation involves computation using `IValues`, 16-byte tagged unions that can hold the concrete representation of any type in TorchScript. TorchScript is statically typed, so it would be possible to operate on unboxed primitive types, but the interface between interpreter, built-in ops and user functions would be significantly more complicated. A single tagged union keeps these interfaces simple and since most objects are `Tensors` anyway, the overhead of storing a tag is small compared to the data stored in the `Tensors`.
@ -1407,7 +1406,7 @@ def foo(a : Tensor, b : Tensor):
```
Will produce a graph like this:
![AliasTracker graph](/docs/source/_static/img/aliastracker_graph.png)
![AliasTracker graph](../../../docs/source/_static/img/aliastracker_graph.png)
A few things to note:
- "Graph Input Element" is an example of an `Element` that isn't a first-class `Value`. Alias analysis happens on a per-function level, so we don't necessarily know the aliasing relationships of the inputs. The only safe assumption is that `a` and `b` may alias each other, so they point to a special `Element` that describes "the world outside of this function".
@ -1459,8 +1458,8 @@ When differentiating a graph, each node that has a symbolic gradient will be inc
Adding/updating symbolic gradient functions must be tested carefully as it's easy to get CI green by comparing autograd result with itself, but potentially cause an autodiff support regression.
If your PR adds/updates a gradient formula for `torch`/`nn` functions, you **MUST** enable/update the corresponding tests in
- `torch` functions: `method_tests` in [common_method_tests.py](../../../test/common_method_tests.py)
- `nn` functions: `nn_functional_tests` in [test_jit.py](../../../test/test_jit.py)
- `torch` functions: `module_tests` in [common_nn.py](../../testing/_internal/common_nn.py)
- `nn` functions: `nn_functional_tests` in [test_jit.py](../../testing/_internal/jit_metaprogramming_utils.py)
To turn on autodiff check, you can add an optional `check_ad(should_autodiff_node[bool], nonfusible_nodes[str|list[str]], fusible_nodes[str|list[str]])` tuple after the optional test variant name field.
If `should_autodiff_node=True`, the differentiated traced/script forward graph must have a `prim::DifferentiableGraph`.

2
torch/csrc/jit/README.md
View File

@ -26,5 +26,5 @@ A brief summary of the source tree:
**Refer** to each folder for more in-depth documentation.
Other relevant parts of the codebase not contained here:
- [aten/src/ATen/core](/aten/src/ATen/core): contains JIT code re-used by other elements of the
- [aten/src/ATen/core](../../../aten/src/ATen/core): contains JIT code re-used by other elements of the
runtime system (eager, mobile, etc.)

4
torch/csrc/profiler/README.md
View File

@ -23,7 +23,7 @@ TODO
## `RecordFunction` ##
[/aten/src/ATen/record_function.h](/aten/src/ATen/record_function.h)
[aten/src/ATen/record_function.h](../../../aten/src/ATen/record_function.h)
`RecordFunction` is used by the profiler to instrument CPU-side events.
@ -38,7 +38,7 @@ There is also a python binding for `RecordFunction` in python (`with torch.profi
The autograd engine is responsible for automatically computing gradients.
The profiler records two pieces of information from the autograd engine:
* [Sequence number](/aten/src/ATen/SequenceNumber.h): this is a unique-per-thread index assigned to each op call(\*) in the forward pass. When a backward op is triggered, it is also assigned a sequence number matching the sequence number of the forward op that caused that backward op to be executed. Using this information, the profiler is able to match forward and backward ops; in chrome traces, this feature can be enabled with the "fwd_bwd" flow events
* [Sequence number](../../../aten/src/ATen/SequenceNumber.h): this is a unique-per-thread index assigned to each op call(\*) in the forward pass. When a backward op is triggered, it is also assigned a sequence number matching the sequence number of the forward op that caused that backward op to be executed. Using this information, the profiler is able to match forward and backward ops; in chrome traces, this feature can be enabled with the "fwd_bwd" flow events
* [Forward thread id](https://github.com/pytorch/pytorch/blob/2e3fce54506ba82eee2c890410bf7a1405a64ec6/aten/src/ATen/record_function.h#L357): Autograd can be used in multi-threaded environments. The forward thread ID indicates the ID of the thread on which the forward op was executed on. This information is needed because the sequence number, mentioned above, is only unique within a thread; the forward thread ID is used for differentiating different ops with the same sequence number.
(\*) Note that only op invocations whose inputs require gradients are assigned a sequence number

4
torch/fx/passes/README.md
View File

@ -12,9 +12,5 @@ This folder contains the pass infrastructure and passes for transforming fx.Grap
* [dialect](dialect) - dialect specific passes
* [common](dialect/common) - common passes that can be shared by all dialects
* [cse_pass.py](dialect/common/cse_pass.py) - a CSE pass
* [aten](dialect/aten) - aten dialect specific passes
* [prims](dialect/prims) - prim dialect specific passes
* [backends](backends) - Backend specific passes
* [nvfuser](backends/nvfuser) - passes for nvfuser
* [operator_support.py](backends/nvfuser/operator_support.py) - nvFuser supported ops
* [conversion](conversion) - Conversion passes between dialects