PEP 836: Clarify that only the frontend is changing (#5023)

Author: Fidget-Spinner

peps/pep-0836.rst

@@ -61,7 +61,11 @@ At a high level, these are our milestones and goals for the JIT over the next
     first implementation should be minimal, may initially use more memory or
     perform slightly worse, and may be rolled back to the current tracing
     frontend if the approach does not meet the project's goals in the first
-    year.
+    year. The rest of the JIT (intermediate representation,
+    middle-end/optimizer, and Copy and Patch backend), remain almost
+    completely unchanged from CPython 3.15. **In other words, only what
+    the JIT selects to compile is evolving from traces to methods,
+    nothing else is changing from CPython 3.15.**.
 
   * :ref:`Make the JIT compatible with free-threading <836-free-threading>`. We
     believe that this is important to prioritize early on in the next phase of
@@ -400,20 +404,21 @@ method frontend are as follows:
 * To enable higher-level optimizations more easily, without requiring a higher
   JIT tier (which requires another JIT bolted on top) or inter-trace knowledge.
 
-The following is the reference design. It is subject to change as the code
-evolves:
-
-* **Uop IR.** The benefits for this are explained in previous sections.
-* **Some Single Static Assignment (SSA) form properties over the stack.** This
-  does not mean we need to rewrite our IR to SSA form, but rather, the
-  optimizer should have some SSA properties. We believe this aligns more
-  closely with other compilers (e.g. Cinder, PyPy, Chrome's V8, CRuby's
-  YJIT/ZJIT), and makes understanding *how* to optimize in the JIT easier and
-  more powerful. The current JIT optimizer already nearly supports this, and
-  only requires minimal changes to have SSA properties. An IR with proper stack
-  discipline already has many useful properties that are analogous to SSA form.
-  SSA form will basically come for free for stack variables.
-* **A simple way to represent high-level constructs.** We have an
+The following is the reference design for the evolved frontend.
+It is subject to change as the code evolves:
+
+* **Compile one or more methods at a time.** This is self-explanatory in the
+  name.
+* **Some Single Static Assignment (SSA) form properties over the stack.**
+  The current CPython 3.15 JIT optimizer already nearly supports this, and
+  only requires minimal changes to have SSA properties. The CPython 3.15
+  Uop IR also already has many useful properties that are analogous to SSA form.
+  We want to introduce a few more SSA properties to the Uop IR.
+  We believe this aligns more closely with other compilers
+  (e.g. Cinder, PyPy, Chrome's V8, CRuby's YJIT/ZJIT), and makes understanding
+  *how* to optimize in the JIT easier and more powerful.
+* **A simple way to represent high-level constructs.** To represent
+  high-level control-flow in the method frontend, we have an
   implementation that forms *regions* (groups of basic blocks), inspired by the
   similarly named concept in MLIR (an LLVM project). Rather than degenerating
   programs to single basic blocks pointing to each other, we opt to keep the
@@ -422,6 +427,8 @@ evolves:
   better generator/coroutine/loop/etc. (high-level construct) analysis and
   optimizations.
 
+**In other words, apart from growing support for analyzing methods,
+nothing has changed from CPython 3.15.**
 With all of the above, most optimizations in the JIT can be implemented as
 local rewrites. This is again, inspired by certain properties of other
 runtimes' intermediate representations. Our goal is to make the JIT more
@@ -561,8 +568,8 @@ pyperformance. For example:
   when it detects that objects are uniquely referenced. This is a source of
   slowdown on architectures where atomics are more expensive.
 
-**We believe that the right framing here is not the JIT *or* free-threading,
-but rather, the JIT *and* free-threading**. We understand the JIT may initially
+**We believe that the right framing here is not the JIT or free-threading,
+but rather, the JIT and free-threading**. We understand the JIT may initially
 lose some performance opportunities from free-threading's semantics. However,
 both the JIT and free-threading have much to gain. The JIT can recover all of
 free-threading's single-threaded performance losses and maybe even more.