Google Git
Sign in
android / platform / external / pytorch / c3f5ba9460 / . / torch / csrc / jit
tree: de615648cb96c895b513bc628fa604c302d12618 [path history] [tgz]
  1. batched/
  2. fuser/
  3. passes/
  4. script/
  5. alias_info.h
  6. argument_spec.h
  7. attributes.cpp
  8. attributes.h
  9. autodiff.cpp
  10. autodiff.h
  11. caffe2_operator.cpp
  12. caffe2_operator.h
  13. catch_utils.hpp
  14. code_template.h
  15. constants.cpp
  16. constants.h
  17. custom_operator.h
  18. dynamic_dag.h
  19. export.cpp
  20. export.h
  21. graph_executor.cpp
  22. graph_executor.h
  23. graph_node_list.h
  24. hooks_for_testing.cpp
  25. hooks_for_testing.h
  26. import.cpp
  27. import.h
  28. import_method.cpp
  29. import_method.h
  30. init.cpp
  31. init.h
  32. interned_strings_class.h
  33. interpreter.cpp
  34. interpreter.h
  35. ir.cpp
  36. ir.h
  37. ir_views.h
  38. named_value.h
  39. netdef_converter.cpp
  40. netdef_converter.h
  41. node_hashing.cpp
  42. node_hashing.h
  43. operator.cpp
  44. operator.h
  45. pybind.h
  46. pybind_utils.h
  47. python_arg_flatten.cpp
  48. python_arg_flatten.h
  49. python_interpreter.cpp
  50. python_ir.cpp
  51. python_ir.h
  52. python_tracer.cpp
  53. python_tracer.h
  54. README.md
  55. register_c10_ops.cpp
  56. register_caffe2_ops.cpp
  57. register_prim_ops.cpp
  58. register_special_ops.cpp
  59. resource_guard.h
  60. scope.cpp
  61. scope.h
  62. source_location.h
  63. source_range.h
  64. symbolic_script.cpp
  65. symbolic_script.h
  66. symbolic_variable.h
  67. tracer.cpp
  68. tracer.h
  69. tracing_state.h
  70. variable_tensor_list.h
torch/csrc/jit/README.md

jit

The jit directory contains infrastructure for a just-in-time compiler for PyTorch and associated ‘script’ subset of python it can execute directly.

The JIT compiler has several phases.

  1. Parsing - An AST (defined in tree_views.h) is generated either by parsing a string of python-like code (jit/script/parser.h) or by translation from the Python AST (jit/frontend.py). This phase only checks for syntactic correctness and for use of the syntactic subset of python that the script supports.

  2. Semantic Checking/Specialization - We lower the AST into an IR Graph object. In this phase we check that variables are in scope and resolve any free variables to python objects. When we find free variables that are python objects, or references to non-first-class values such as modules, we temporarily represent them as SugaredValue objects. This phase then de-sugars these values by e.g. inserting a PythonOp into the graph to call a python function.

  3. Optimizations - A GraphExecutor works on an initial Graph object, performing optimizations, possibly differentiating it, and possibly specializing it to a particular size.

  4. Translation to Instructions - to execute a graph, it is lowered by the interpreter into a linear list of Instruction objects.

  5. Execution - the interpreter reads the instruction stream, executing ATen operations and any generated code fragments.

Well-known functions

Ordinarily, when defining a compiler you want the set of functions to be user extensible; e.g., a user can add to the set of defined functions by defining an appropriate autograd Function. However, there are some functions where we want to make assumptions about their semantics, because we are going to write optimizations over them or insert them into the program. Such functions are “well-known” functions, because the JIT compiler knows about them, and a user implementation must abide by the contract (sometimes implicitly) specified by the compiler.

A well-known function is usually implemented in several parts:

  • First, we pre-intern the string (interned_strings.h) that identifies the node. This allows us to more conveniently refer to these operators without having to first do a lookup through the intern table.

  • If we generate this operator during optimizations, we will often have a helper function in Graph (ir.h) for creating the operator. This is the easiest way to find out, in code, what attributes we assume for an operator.

  • There is a runtime interpretation of the operator in torch/csrc/autograd/functions/interpreter.cpp, which specifies how we actually interpret programs that contain such an operator.

So, whence the specifications! For the most part, we are following the ONNX operator specification to determine the semantics of our operators. However, there are a few other well-known functions which are specific to PyTorch.

  • FusionGroup

    A fusion group takes some number of input tensors, applies a graph Subgraph to them, producing the returned tensors of the subgraph. Operationally, operators inside a FusionGroup are fused into a single kernel, so that their intermediate results are never materialized. Not all operators support fusion:

    • attribute:
    • input: 1 - ∞ (same as inputs of Subgraph)
    • output: 1 - ∞ (same as outputs of Subgraph)