Reusing identical subexpressions

This overview explains how common subexpression elimination identifies matching structure and reuses a computed value. Avoiding repeated work requires a valid structural identity, rather than a matching output on one convenient input. Two policy routes both require staff status and verification. The ordinary route also requires being in the office; the exception route requires special approval. Naming the shared condition S lets both routes refer to the same intermediate calculation. For a verified staff member, S is one. Store that value in a slot for this evaluation. The slot has a meaning and a lifetime: it holds the shared condition for the current input, not a permanent answer for all future requests. With office zero and exception one, the ordinary route returns zero while the exception route returns one. Both consume the same stored S. Their or returns one, so the request succeeds through the exception route. Sharing S preserves both route meanings. Common subexpression elimination identifies matching structure and reuses the result. The repeated-subexpression rule contains two written occurrences of S, which equals A AND B. Each occurrence has a structural key that includes AND and the identities of its inputs. When the keys match under the chosen contract, both occurrences refer to one result slot for S. The left branch reads that slot with C and D; the right reads it with E. At 11011 the final answer remains one. Across all 32 assignments, the teaching check gives identical outputs for repeated computation and reuse of the saved value. Sharing a subtree does not automatically flatten an associative chain, and it does not establish a time gain. Key construction and bookkeeping cost something too. This episode owns reuse of identical work; the next owns safe flattening. Return to the four-condition staff policy. S means staff and verified; L means S and office; R means S and exception; the answer is L or R. The intervening thirty-two-case check belongs to the separate five-input compiler example. Here staff, verified, office and exception are one, zero, one and one. The missing verification makes S zero. Both consumers use that same zero, so neither the office condition nor the exception condition can make its and route true. Their final or is zero. This verifies that sharing preserves a required condition instead of accidentally treating it as optional. This case establishes a specific contrast. Both routes still require S. Sharing must preserve the policy. Keep the input, intermediate values, and conclusion together when comparing it with the previous case. The calculated answer belongs to this complete assignment under the stated rule. A naive eager tree computes the shared condition twice. Common-subexpression elimination can remove one of those identical calculations. That is a structural saving we can count directly under the declared traversal model. The shared version also needs a way to keep and retrieve the result. For a large expensive subexpression that can be valuable. For a tiny operation, bookkeeping may offset the saved work. An instruction count alone does not measure that balance. First establish that the rewrite preserves every assignment. Then measure comparable complete tasks, with preparation and delivery handled consistently. A correct sharing transformation is not automatically a performance win on every workload. Include both the operation and its inputs in the key. Account for lookup and bookkeeping before claiming a time gain.