summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAshvika Maddikonda <ashvika@vector35.com>2026-05-12 17:14:19 -0400
committerJordan <github@psifertex.com>2026-05-13 14:32:33 +0200
commit7704d4dd39e8666adb242192a885ae11c5bcc1b6 (patch)
tree8e2ff6eda31c1d815428f1c48e87327aed1a9ddc
parent6de62ea60d13cdd4fd4a97942fff1ad679b47924 (diff)
changed "it's" to "its" (grammar)
-rw-r--r--docs/dev/concepts.md2
1 files changed, 1 insertions, 1 deletions
diff --git a/docs/dev/concepts.md b/docs/dev/concepts.md
index feebd48a..14756160 100644
--- a/docs/dev/concepts.md
+++ b/docs/dev/concepts.md
@@ -153,7 +153,7 @@ It is easy to confuse ExpressionIndex and InstructionIndex properties in the API
Our [BNIL Overview](bnil-overview.md) mentions Static Single Assignment (SSA) without explaining what it is. You can of course always check out [Wikipedia](https://en.wikipedia.org/wiki/Static_single-assignment_form), but here's a quick summary of what it is, why we expose multiple SSA forms of our ILs and how you can use it to improve your plugin writing with BNIL.
-At it's simplest, SSA forms of an Intermediate Language or Intermediate Representation are those in which variables are read only. They can be set when created, but not modified. Instead of modifying them, when you make a change, a new "version" of the variable is created denoting that the value has changed in some way. While this certainly makes the form less readable to humans, this means it's actually really easy to walk back and see how a variable has been modified by simply looking at the definition site for a given variable or all possible versions before it. Any time the variable is modified, a new version of that variable will be created (you'll see `#` followed by a number indicating that this is a new version).
+At its simplest, SSA forms of an Intermediate Language or Intermediate Representation are those in which variables are read only. They can be set when created, but not modified. Instead of modifying them, when you make a change, a new "version" of the variable is created denoting that the value has changed in some way. While this certainly makes the form less readable to humans, this means it's actually really easy to walk back and see how a variable has been modified by simply looking at the definition site for a given variable or all possible versions before it. Any time the variable is modified, a new version of that variable will be created (you'll see `#` followed by a number indicating that this is a new version).
But what if the code takes multiple paths and could have different values depending on the path that was taken? SSA forms use a `Φ` (pronounced either as "fee" or "fi" like "fly" depending on which mathematician or Greek speaker you ask!) function to solve this ambiguity. All a `Φ` function does is aggregate different versions of a variable when entering a basic block with multiple paths. So a basic block with two incoming edges where `eax` is modified might have something like: `eax#3 = Φ(eax#1, eax#2)` denoting that the new version of the variable could have come from either of those sources.