accelforge 0.0.1__py3-none-any.whl

docs/_build/html/_sources/notes/modeling.rst.txt

@@ -0,0 +1,33 @@
+How Modeling Works
+==================
+
+.. _accelerator-modeling:
+
+Modeling calculates the energy, area, and latency of an architecture running a given
+workload. This is done in three steps:
+
+1. **Per-Component Energy, Area, and Leakage**: This step models the area and leakage
+   power of each :py:class:`~fastfusion.frontend.arch.Component` in the architecture.
+   It then generates *per-action energy*, which is used by later steps in the model to
+   find the energy of performing hardware
+   :py:class:`~fastfusion.frontend.arch.ComponentAction`\ s.
+
+2. **Mapping the Workload onto the Accelerator**: This step generates mappings
+   :py:class:`~fastfusion.frontend.mapping.Mapping`\ s that map the workload onto the
+   hardware.
+
+3. **Modeling the Energy, Area, and Latency of the Mapping**: This step looks at the
+   full mapping and calculates the number of hardware actions that occur, using it to
+   total the energy and area of the accelerator.
+
+In this package, the mapping and modeling steps are connected, letting the mapper
+quickly find mappings that minimize the energy and latency of the accelerator.
+
+These steps are detailed in the following sections:
+
+.. toctree::
+   :maxdepth: 1
+
+   modeling/component_energy_area
+   modeling/accelerator_energy_latency
+   modeling/mapping

docs/_build/html/_sources/notes/parsing/arithmetic_parsing.rst.txt

@@ -0,0 +1,136 @@
+Arithmetic and Parsing
+======================
+
+Objects can include expressions that are parsed when the
+:py:class:`~fastfusion.frontend.spec.Spec` is parsed. Parsing occurs when the
+:py:func:`~fastfusion.frontend.spec.Spec` is going to be used to model the energy, area,
+or latency of an accelerator, such as when the
+:py:func:`~fastfusion.frontend.spec.Spec.calculate_component_energy_area` method is
+called.
+
+To-be-parsed expressions can include Python code, and supported
+operations include many standard library functions (*e.g.,* ``range``, ``min``) and
+functions from the ``math`` standard library (*e.g.,* ``log2``, ``ceil``).
+
+The scope available for parsing includes the following in order of increasing
+precedence:
+
+- Variables defined in a top-level :py:class:`~fastfusion.frontend.variables.Variables`
+  object.
+- Variables defined in outer-level YAML objects. Dictionary keys can be referenced by
+  names, and list entries by index. The dot syntax can be used to access dictionaries;
+  for example, ``x.y.z`` is equivalent to ``outer_scope["x"]["y"]["z"]``.
+- Variables defined in the current YAML object. Dictionary keys may reference each other
+  as long as references are not cyclic.
+
+The following is an example of valid parsed data:
+
+.. code-block:: yaml
+
+  variables:
+    a: 123
+    b: a + 5
+    c: min(b, 3)
+    d: sum(y for y in range(1, 10))
+
+  # In some later scope
+  ... outer_scope:
+    x: 123
+    y: a + x # Reference top-level variables
+    inner_scope:
+        a: 3 # Override outer scope
+        b: outer_scope.x
+        # Statements can be out-of-order if not cyclic referencing
+        firt_item: second_item
+        second_item: 3
+
+Additionally, values can be set directly in Python code. For example:
+
+.. code-block:: python
+
+  from fastfusion.frontend.arch import ComponentAttributes
+  attributes = ComponentAttributes(
+    value1=123,
+    value2="value1 + 5"
+    # ... other attributes
+  )
+
+
+Supported Arithmetic Operations
+-------------------------------
+
+The following are available expressions. In addition to the below, Python keywords that
+are available witout import (*e.g.,* ``min``) are also available
+
+- ``ceil``: :py:func:`math.ceil`
+- ``comb``: `math.comb`
+- ``copysign``: `math.copysign`
+- ``fabs``: :py:func:`math.fabs`
+- ``factorial``: :py:func:`math.factorial`
+- ``floor``: :py:func:`math.floor`
+- ``fmod``: :py:func:`math.fmod`
+- ``frexp``: :py:func:`math.frexp`
+- ``fsum``: :py:func:`math.fsum`
+- ``gcd``: :py:func:`math.gcd`
+- ``isclose``: `math.isclose`
+- ``isfinite``: :py:func:`math.isfinite`
+- ``isinf``: :py:func:`math.isinf`
+- ``isnan``: :py:func:`math.isnan`
+- ``isqrt``: :py:func:`math.isqrt`
+- ``ldexp``: :py:func:`math.ldexp`
+- ``modf``: :py:func:`math.modf`
+- ``perm``: :py:func:`math.perm`
+- ``prod``: :py:func:`math.prod`
+- ``remainder``: :py:func:`math.remainder`
+- ``trunc``: :py:func:`math.trunc`
+- ``exp``: :py:func:`math.exp`
+- ``expm1``: :py:func:`math.expm1`
+- ``log``: :py:func:`math.log`
+- ``log1p``: :py:func:`math.log1p`
+- ``log2``: :py:func:`math.log2`
+- ``log10``: :py:func:`math.log10`
+- ``pow``: :py:func:`math.pow`
+- ``sqrt``: :py:func:`math.sqrt`
+- ``acos``: :py:func:`math.acos`
+- ``asin``: :py:func:`math.asin`
+- ``atan``: :py:func:`math.atan`
+- ``atan2``: :py:func:`math.atan2`
+- ``cos``: :py:func:`math.cos`
+- ``dist``: :py:func:`math.dist`
+- ``hypot``: :py:func:`math.hypot`
+- ``sin``: :py:func:`math.sin`
+- ``tan``: :py:func:`math.tan`
+- ``degrees``: :py:func:`math.degrees`
+- ``radians``: :py:func:`math.radians`
+- ``acosh``: :py:func:`math.acosh`
+- ``asinh``: :py:func:`math.asinh`
+- ``atanh``: :py:func:`math.atanh`
+- ``cosh``: :py:func:`math.cosh`
+- ``sinh``: :py:func:`math.sinh`
+- ``tanh``: :py:func:`math.tanh`
+- ``erf``: :py:func:`math.erf`
+- ``erfc``: :py:func:`math.erfc`
+- ``gamma``: :py:func:`math.gamma`
+- ``lgamma``: :py:func:`math.lgamma`
+- ``pi``: :py:func:`math.pi`
+- ``e``: :py:func:`math.e`
+- ``tau``: :py:func:`math.tau`
+- ``inf``: :py:func:`math.inf`
+- ``nan``: :py:func:`math.nan`
+- ``abs``: :py:func:`abs`
+- ``round``: :py:func:`round`
+- ``pow``: :py:func:`pow`
+- ``sum``: :py:func:`sum`
+- ``range``: :py:func:`range`
+- ``len``: :py:func:`len`
+- ``min``: :py:func:`min`
+- ``max``: :py:func:`max`
+- ``float``: :py:func:`float`
+- ``int``: :py:func:`int`
+- ``str``: :py:func:`str`
+- ``bool``: :py:func:`bool`
+- ``list``: :py:func:`list`
+- ``tuple``: :py:func:`tuple`
+- ``enumerate``: :py:func:`enumerate`
+- ``getcwd``: :py:func:`os.getcwd`
+- ``map``: :py:func:`map`

docs/_build/html/_sources/notes/parsing/setexpressions.rst.txt

@@ -0,0 +1,63 @@
+.. _set-expressions:
+
+Set Expressions
+===============
+
+Set expressions are used to describe sets of tensors and rank variables. Set expressions
+are parsed for each pmapping template, meaning that they can reference specific tensors
+for each Einsum.
+
+As an example of a set expression, we can describe all tensors that are not intermediates
+using the following:
+
+.. code-block:: yaml
+
+    ~Intermediates
+
+Set expressions can use the full Python syntax, including the following:
+
+- ``&``: Intersection
+- ``|``: Union
+- ``~``: Complement
+- ``-``: Difference
+
+You may also use Pythonic language with set expressions in some locations. For example,
+we may want to use input tensors if and only if there are three or fewer total tensors:
+
+.. code-block:: yaml
+
+    Inputs if len(All) > 3 else All
+
+Set expressions are parsed for every Einsum + Flattened-Architecture:ref:`flattening`
+combination. The following set expressions are supported:
+
+- ``All``: All tensors used in the current Einsum.
+- ``Inputs``: Tensors input to the current Einsum.
+- ``Intermediates``: Tensors produced by one Einsum and consumed by another.
+- ``Nothing``: The empty set.
+- ``Outputs``: Tensors output from the current Einsum.
+- ``Persistent``: Tensors that must remain in backing storage for the full duration of
+  the workload's execution. See:ref:`persistent-tensors`.
+- ``Shared``: Tensors that are shared between multiple Einsums.
+- ``Tensors``: Alias for ``All``.
+
+Additionally, the following special variables are available:
+
+- ``<Any Tensor Name>``: Resolves to the tensor with the given name. If the tensor is
+  not used in the current Einsum, then it resolves to the empty set.
+- ``Einsum``: The name of the currently-processed Einsum. May be used in expressions
+  such as ``Inputs if Einsum == "Conv" else All``.
+- ``EinsumObject``: For complex logic using the Einsum object directly.
+- ``MemoryObject.Tensors``: The set of all tensors that are stored in the memory object.
+  Architectures are parsed from the top down, so this will only be available
+  ``MemoryObject`` has been parsed. Lower-level memory objects may reference upper-level
+  memory objects, but not vice versa.
+
+All tensor expressions can be converted into relevant rank variables by accessing
+``.rank_variables``, which will return the set of all rank variables that index into the
+tensor. If multiple tensors are referenced, then the union of all indexing rank
+variables is returned. For example, `MemoryObject.Tensors.rank_variables` will return
+the set of all rank variables that index into any of the tensors stored in
+`MemoryObject`.
+
+Additional keys can be defined following :ref:`renaming-tensors-rank-variables`.

docs/_build/html/_sources/notes/parsing/yaml_parsing.rst.txt

@@ -0,0 +1,176 @@
+YAML Parsing
+============
+
+FastFusion inputs can be parsed from YAML files. YAML parsing occurs once when YAML
+files are loaded into Python.
+
+We use an extended version of the standard YAML syntax, including the ``<<`` and ``<<<``
+operators. ``<<``, when used as a dictionary key, will merge the contents of its value
+with the current dictionary. ``<<<`` will merge the contents of its value and will merge
+nested dictionaries. The ``!nomerge`` tag will block merging from occuring.
+
+The following is a YAML parsing cheat sheet:
+
+.. code-block:: yaml
+
+  # YAML Nodes
+  listNode:
+  - element1
+  - element2
+
+  dict_node:
+    key1: value1
+    key2: value2
+
+  # Styles
+  list_block_style:
+  - element1
+  - element2
+  list_flow_style: {element1, element2}
+
+  dict_block_style:
+    key1: value1
+    key2: value2
+  dict_flow_style: {key1: value1, key2: value2}
+
+  # Anchors, Aliases, and Merge Keys
+
+  # Anchors
+  anchored_list_flow_style: &my_anchored_list
+  - element1
+  - element2
+  anchored_list_block_style: &my_anchored_list [1, 2, 3, 4, 5]
+
+  anchored_dict_flow_style: &my_anchored_dict
+    key1: value1
+    key2: value2
+  anchored_dict_block_style: &my_anchored_dict {key1: value1, key2: value2}
+
+  # Aliases
+  my_list_alias: *my_anchored_list
+  result_of_my_list_alias: [1, 2, 3, 4, 5]
+
+  my_dict_alias: *my_anchored_dict
+  result_of_my_dict_alias: {key1: value1, key2: value2}
+
+  # Merge Keys
+  anchored_dict_1: &my_anchored_dict
+    key1: value1_dict1
+    key2: value2_dict1
+
+  anchored_dict_2: &my_anchored_dict2
+    key2: value2_dict2
+    key3: value3_dict2
+
+  merged_dict:
+    <<: [*my_anchored_dict, *my_anchored_dict2] # My_anchored_dict takes precedence
+
+  result_of_merged_dict:
+    key1: value1_dict1
+    key2: value2_dict1 # Earlier anchors take precedence
+    key3: value3_dict2
+
+  merged_dict2:
+    <<: *my_anchored_dict
+    value2: override_value2 # Override value2
+
+  result_of_merged_dict2:
+    key1: value1_dict1
+    key2: override_value2
+
+  # Hierarchical Merge Keys
+  anchored_dict_hierarchical_1: &my_anchored_dict
+    key1: value1_dict1
+    key2: {subkey1: subvalue1, subkey2: subvalue2}
+    mylist: [d, e, f]
+    mylist_nomerge: [4, 5, 6]
+
+  merged_dict_hierarchical:
+    <<<: *my_anchored_dict
+    key2: {subkey1: override1} # subkey2: subvalue2 will come from the merge
+    mylist: [a, b, c]
+    mylist_nomerge: !nomerge [1, 2, 3]
+
+  result_of_merged_dict_hierarchical:
+    key1: value1_dict1
+    key2: {subkey1: override1, subkey2: subvalue2}
+    mylist: [a, b, c, d, e, f]
+    mylist_nomerge: [1, 2, 3]
+
+  merged_dict_non_hierarchical:
+    <<: *my_anchored_dict
+    key2: {subkey1: override1} # This will override all of key2
+    mylist: [a, b, c]
+    mylist_nomerge: !nomerge [1, 2, 3]
+
+  result_of_merged_dict_non_hierarchical:
+    key1: value1_dict1
+    key2: {subkey1: override1}
+    mylist: [a, b, c]
+    mylist_nomerge: [1, 2, 3]
+
+
+
+Jinja2 Templating
+-----------------
+
+We also support Jinja2 templating. To substitute Jinja2 variables, the
+``jinja_parse_data`` argument can be passed to the
+:py:meth:`~fastfusion.util.basetypes.FromYAMLAble.from_yaml` function. Additional Jinja2
+functions are also supported, including:
+
+- ``add_to_path(path)``: Add a path to the search path for the ``include`` function.
+
+- ``cwd()``: Return the current working directory.
+
+- ``find_path(path)``: Find a file in the search path and return the path to the file.
+
+- ``include(path, key)``: Include a file and return the value of the key. For example,
+  ``include(path/x.yaml, a)`` will open the file ``path/x.yaml``, look for a top-level
+  dictionary, and return the ``a`` key from that dictionary. Multiple levels of indexing
+  can be used, such as ``include(path/x.yaml, a.b.c)``.
+
+- ``include_all(path, key)``: Include all files in a directory and return the value of the
+  key. For example, ``include_all(path/dir, a)`` will open all files in the directory
+  ``path/dir``, look for a top-level dictionary, and return the ``a`` key from that dictionary.
+
+- ``include_text(path)``: Include a file and return the text of the file.
+
+- ``path_exists(path)``: Check if a file exists in the search path.
+
+The following is a Jinja2 template cheat sheet:
+
+.. code-block:: yaml
+
+  # Add files to be included in the environment
+  {{add_to_path('path/to/some/dir')}}
+  {{add_to_path('path/to/some/other/dir')}}
+
+  variables:
+    var1: 5
+    var3: "{{cwd()}}/some_file.yaml" # {{cwd()}} is the directory of this file
+    var4: "{{find_path('some_file.yaml')}}" # find_path searches all paths added by add_to_path
+    var5: {{set_by_jinja}} # Sets the value to a "set_by_jinja" variable that must be defined
+
+    {% if path_exists('some_file.yaml') %} # Check if a file exists
+    var6: "some_file.yaml exists" # Include this line if the file exists
+    {% else %}
+
+  arch:
+    # Include a subset of the file. Index into the structure with
+    # dot-separated keys.
+    nodes: {{include('other.arch.yaml', 'arch.nodes')}}
+
+  # Include the entire file
+  {{include_text('grab_text_from_file.yaml')}}
+
+  compound_components:
+    # Include the subsets of multiple files. They will be merged into one list.
+    classes: {{include_all('compound_components/*.yaml', 'compound_components.classes')}}
+
+
+  {% if enable_text_flag|default(False) %}
+  text_included_if_enable_text_flag_is_true: |
+    This text will be included if enable_text_flag is true. The |default(False) sets
+    the default value of enable_text_flag to False if it is not set.
+  {% endif %}

docs/_build/html/_sources/notes/quickstart_and_installation.rst.txt

@@ -0,0 +1,9 @@
+Installation
+============
+
+FastFusion can be installed with pip:
+
+```bash
+pip install fastfusion
+```
+

docs/_build/html/_sources/notes/spec/architecture.rst.txt

@@ -0,0 +1,133 @@
+Arch Specification
+==================
+
+The architecture, defined by the :py:class:`~fastfusion.frontend.arch.Arch` class,
+describes the hardware that is running the workload. An architecture is represented as a
+tree, where branches in the tree represent different compute paths that may be taken.
+For the rest of this section, we will assume that the architecture has been *flattened*,
+meaning that there are no branches in the tree. The flattening procedure is described in
+:ref:`flattening`.
+
+A flattened architecture is a hierarchy of components with a
+:py:class:`~fastfusion.frontend.arch.Compute` at the bottom. The following components
+are supported:
+
+- :py:class:`~fastfusion.frontend.arch.Memory` components store and reuse data.
+- :py:class:`~fastfusion.frontend.arch.ProcessingStage` components perform some
+  non-compute action (*e.g.,* quantizing or transferring data).
+- :py:class:`~fastfusion.frontend.arch.Compute` components performs the Einsum's
+  computation.
+
+In the architecture file, each component is represented by a YAML dictionary. Component
+types are preceded by the ``!`` character. An example architecture is shown below:
+
+.. include:: ../../../../examples/arches/tpu_v4i_like.arch.yaml
+   :code: yaml
+
+
+Flattening
+----------
+
+A given Einsum may be executed only on a single
+:py:class:`~fastfusion.frontend.arch.Compute`, and it may use hardware objects between
+the root of the tree and the leaf for that
+:py:class:`~fastfusion.frontend.arch.Compute`. Flattening an architecture converts a
+tree architecture into multiple parallel *Flattened-Architectures*, each one
+representing one possible path from the root of the tree to the leaf for that
+:py:class:`~fastfusion.frontend.arch.Compute`.
+
+For example, in the architecture above, there are two compute units, the ``scalar_unit``
+and the ``mac``. Flattening this architecture will produce two Flattened-Architectures;
+one with a ``scalar_unit`` and one with a ``mac``. The partial mappings for each of
+these architectures can be combined, and can share hardware that exists above both
+compute units.
+
+Inserting a :py:class:`~fastfusion.frontend.arch.Compute` directly into the top-level
+architecture hierarchy will create an optional compute path that goes from the top node
+to the compute. More complex topologies (*e.g.,* give an upper-level compute a private
+cache) can be created by creating sub-branches following :ref:`sub-branches`.
+
+
+Sub-Branches
+------------
+
+.. _sub-branches:
+
+Sub-branches in the architecture can represent different execution paths. The following
+branch types are supported:
+
+- :py:class:`~fastfusion.frontend.arch.Parallel` represents multiple parallel branches,
+  one of which is executed.
+- :py:class:`~fastfusion.frontend.arch.Hierarchical` represents a single hierarchy,
+  where each node is a parent of the following nodes.
+
+Sub-branches are written with the following syntax:
+
+.. code-block:: yaml
+
+  - !Memory
+    ...
+
+  - !Memory
+    ...
+
+  - !Parallel
+    nodes:
+    - !Hierarchical
+      nodes:
+      - ... # First-branch nodes
+    - !Hierarchical
+      nodes:
+      - ... # Second-branch nodes
+
+  # If more nodes go down here, they are children of the outer-level node, not the
+  !Parallel node.
+  - !Memory
+    ...
+
+The top-level :py:class:`~fastfusion.frontend.arch.Arch` is a
+:py:class:`~fastfusion.frontend.arch.Hierarchical`.
+
+
+Spatial Fanouts
+---------------
+
+Spatial fanouts describe the spatial organization of components in the architecture. Any
+component may have spatial fanouts, and fanouts are allowed in any dimension. For
+example, in the architecture above, the ``LocalBuffer`` component has a size-4 spatial
+fanout in the ``Z`` dimension, meaning that there are 4 instances of the component. All
+child components are duplicated in the ``Z`` dimension as well.
+
+The ``ArrayFanout`` component also has a spatial fanout in two dimensions, the
+``reuse_input`` and ``reuse_output`` dimensions.
+:py:class:`~fastfusion.frontend.arch.Fanout` components can be used to instantiate
+spatial fanouts.
+
+Reuse in spatial dimensions may be controlled with the ``may_reuse`` keyword, which
+takes in a set expression that is parsed according to :ref:`set-expressions`. In the
+example, nothing is reused spatially betweeen ``LocalBuffer`` instances, while inputs
+and outputs are reused across registers in the ``reuse_input`` and ``reuse_output``
+dimensions, respectively. Additionally, the ``must_reuse`` keyword can be used to force
+reuse; for example, ``must_reuse: input`` means that all spatial instances must use the
+same input values, else the mapping will be invalid.
+
+Spatial fanouts support the following keywords:
+
+.. include-attrs:: fastfusion.frontend.arch.Spatial
+
+Tensor Holders
+--------------
+
+Tensor holders, which include :py:class:`~fastfusion.frontend.arch.Memory` and
+:py:class:`~fastfusion.frontend.arch.Fanout` components, hold tensors. Each of them
+support extra attributes in their ``attributes`` field, so check
+:py:class:`~fastfusion.frontend.arch.MemoryAttributes` and
+:py:class:`~fastfusion.frontend.arch.FanoutAttributes` for more information on the
+attributes that they support.
+
+Additionally, they have an additional ``tensors`` field, which is used to define the
+tensors that are held by the component. They are represented by the
+:py:class:`~fastfusion.frontend.constraints.Tensors` class, which supports the following
+fields:
+
+.. include-attrs:: fastfusion.frontend.constraints.Tensors

docs/_build/html/_sources/notes/spec/mapping.rst.txt

@@ -0,0 +1,12 @@
+.. _specifying-mapping:
+
+Mapping Specification
+=====================
+
+
+
+What is a LoopTree
+------------------
+
+Reading LoopTrees
+-----------------

docs/_build/html/_sources/notes/spec/workload.rst.txt

@@ -0,0 +1,83 @@
+.. _specifying-workload:
+
+Workload and Renames Specification
+==================================
+
+The :py:class:`~fastfusion.frontend.workload` object describes a cascade of
+Einsums. An Einsum, described in ..., can represent a variety of tensor algebra kernels,
+and a cascade of Einsums is a list of Einsums with data dependencies.
+
+The following is an example workload for three back-to-back matrix multiplications:
+
+.. include:: ../../../../examples/workloads/three_matmuls.workload.yaml
+   :code: yaml
+
+The top-level Workload spec has the following attributes:
+
+.. include-attrs:: fastfusion.frontend.workload
+
+Each Einsum in the workload represents a single Einsum with the following attributes:
+
+.. include-attrs:: fastfusion.frontend.workload.Einsum
+
+And each tensor access has the following attributes:
+
+.. include-attrs:: fastfusion.frontend.workload.TensorAccess
+
+Workloads include *ranks* and *rank variables*. Ranks are the dimensions of the tensors
+in the Einsum, while rank variables are variables that index into these ranks. Generally
+the rank names are uppercased versions of the rank variable names, but not always. In
+more-complex workloads (such as the GPT example later in this doc), there may be cases
+where we index into a rank with multiple different rank variables-- in this case, we may
+use a projection dictionary instead of a list.
+
+.. code-block:: yaml
+
+  - name: Matmul0
+    tensor_accesses:
+    - {name: T0, projection: [m, n0]} # Implies projection: {M: m, N0: n0}
+    - {name: W1, projection: [k, n0]} # Implies projection: {K: k, N0: n0}
+    - {name: T1, projection: [n0, n1], output: True} # Implies projection: {N0: n0, N1: n1}
+
+  - name: Matmul1
+    tensor_accesses:
+    # We can be explicit about the projection
+    - {name: T1, projection: {M: m, N1: n1}}
+    - {name: W1, projection: {N1: n1, N2: n2}}
+    - {name: T2, projection: {M: m, N2: n2}, output: True}
+
+Renaming Tensors and Rank Variables
+-----------------------------------
+:label:`renaming-tensors-rank-variables`
+
+Renames allow us to write simple, generic names (*e.g.,* ``input``,
+``reduced_rank_variable``) in our set expresssions and have them resolve to tensors or
+rank variable in the Einsum.
+
+Each Einsum object has a ``renames`` attribute. This attribute may be populated with one
+of the following:
+
+- A dictionary of ``{new_name: source_set_expression}`` expressions, where
+  ``source_set_expression`` may resolve either to tensors or rank variables. This is the
+  simplest method.
+- A list of dictionaries, each one having the structure ``{name: new_name, source:
+  source_set_expression, expected_count: 1}``. This method allows you to write an
+  expected count, which is optional, and checks that your set expression returned the
+  expected number of elements. For example, if your source set expression were
+  ``Outputs()``, an expected count of 1 would pass if there were only one output tensor,
+  but fail if there were two.
+
+
+Additionally, you may define a separate top-level
+:py:class:`~fastfusion.frontend.renames.Renames` object with structure mirroring the
+workload. For example, one is in the bottom of the following workload:
+
+.. include:: ../../../../examples/workloads/gpt3_6.7B.workload.yaml
+   :code: yaml
+
+This renames format includes, for every Einsum, a ``tensor_accesses`` key and a
+``rank_variables`` key. Both support the above dictionary or list-of-dictionary rename
+formats.
+
+If an Einsum in the renames is named ``default``, then its renames are applied to every
+Einsum unless overridden.

docs/_build/html/_sources/notes/spec.rst.txt

@@ -0,0 +1,36 @@
+Input Specifications
+====================
+
+The :py:class:`~fastfusion.frontend.spec.Spec` class is the main class that contains all
+inputs to this framework. It includes the following:
+
+.. include-attrs:: fastfusion.frontend.spec.Spec
+
+Some of the Spec's inputs are described in the following sections:
+
+.. toctree::
+   :maxdepth: 1
+
+   spec/architecture
+   spec/mapping
+   spec/workload
+
+Input Parsing
+-------------
+
+Input specifications can include arithmetic expressions and set expressions. The parsing
+is described in the following:
+
+.. toctree::
+   :maxdepth: 1
+
+   parsing/arithmetic_parsing
+   parsing/setexpressions
+
+Additionally, inputs can be specified with YAML files using an extend YAML syntax, which
+is described in the following:
+
+.. toctree::
+   :maxdepth: 1
+
+   parsing/yaml_parsing