Section 52: Compiler Optimization Safety¶

TECHSPEC-52 — Section 52 · Version 0.1 · Status: Initial Draft

Status: draft. This section is an Initial Draft (Section 57 is a Working Register). It describes intended or proposed behavior, not a finalized, implemented language rule. Do not treat examples here as normative.

1. Purpose¶

Compiler optimizations improve performance by transforming program representations.

An optimization is valid only when it preserves the source language's specified observable behavior.

2. Semantic Preservation¶

Optimizations must preserve: - Return values. - Declared failures. - Side effects and their required order. - Contract behavior. - Permission checks. - Ownership and lifetime rules. - Observable concurrency semantics. - Required logging and audit behavior. - Resource guarantees explicitly promised by the language.

The language must define which behaviors are observable.

3. Optimization Classes¶

Potential optimizations include: - Constant folding. - Dead-code elimination. - Common subexpression elimination. - Inlining. - Loop transformations. - Allocation elimination. - Devirtualization. - Code specialization.

Each optimization must have documented applicability conditions.

4. Side Effects and Exceptions¶

The compiler must not remove or reorder operations when doing so changes observable effects or failure behavior.

An expression that may fail or perform an effect cannot be treated as a pure value unless analysis establishes the required property.

5. Contracts and Runtime Checks¶

The compiler may remove redundant runtime checks only when it has sufficient evidence that the check is unnecessary under all relevant execution paths.

A check must not be removed merely because: - A developer declared it unnecessary. - A previous test passed. - The compiler assumes typical input. - An optimization flag requests aggressive behavior.

6. Debugging and Traceability¶

Optimized builds should preserve useful source mappings and diagnostic information where practical.

If optimization changes the availability or ordering of execution traces, that limitation must be documented.

7. Optimization Modes¶

Optimization modes may control performance tradeoffs, but none may disable mandatory language safety rules silently.

Any mode that weakens checks must be explicit, restricted, and visible in build metadata. Critical safety checks cannot be bypassed by ordinary optimization settings.

8. Testing¶

The compiler must test optimized and unoptimized behavior against the same conformance cases.

Differential testing can reveal compiler defects but is not a proof of semantic preservation.

9. Verification Evidence¶

Reports should identify: - Compiler version. - Optimization settings. - Applied transformations where available. - Safety checks retained or removed. - Evidence supporting transformations. - Known limitations.

10. Design Goal¶

Optimization must improve implementation efficiency without changing what the program means.

Source file: TECHSPEC-52.md (preserved in source-original/LANG/). See the specification index, the glossary, and the cross-reference index.