# Phase 64: Backend Pruning via Compile-time Constants (DCE)

**Status**: ❌ NO-GO (Regression: -4.05%)

## Executive Summary

Phase 64 attempted to optimize hakmem by making unused backend allocation paths (MID_V3, POOL_V2) unreachable at compile-time, enabling LTO Dead Code Elimination (DCE) to remove them entirely from the binary. The expected target was **+5-10% performance gain** via code size reduction and improved I-cache locality.

**Result**: The strategy achieved significant instruction reduction (-26%, from 3.87B to 2.87B per operation) but produced a **-4.05% throughput regression** on the Mixed workload, failing the +2.0% GO threshold.

## Implementation

### Build Flags Added
- `HAKMEM_FAST_PROFILE_PRUNE_BACKENDS=1`: Master switch to activate backend pruning

### Code Changes
1. **hak_alloc_api.inc.h** (lines 83-120): Wrapped MID_V3 alloc dispatch with `#if !HAKMEM_FAST_PROFILE_PRUNE_BACKENDS`
2. **hak_free_api.inc.h** (lines 242-283): Wrapped MID_V3 free dispatch (both SSOT=1 and SSOT=0 paths)
3. **mid_hotbox_v3_env_box.h** (lines 15-33): Added compile-time constant `mid_v3_enabled()` returning 0
4. **pool_config_box.h** (lines 20-33): Added compile-time constant `hak_pool_v2_enabled()` returning 0
5. **learner_env_box.h** (lines 18-20): Added pruning flag to learning layer disable condition
6. **Makefile** (lines 672-680): Added target `bench_random_mixed_hakmem_fast_pruned`

## A/B Test Results (10 runs each)

### Baseline: bench_random_mixed_hakmem_minimal
```
Run 1:  60,022,164 ops/s
Run 2:  57,772,821 ops/s
Run 3:  59,633,856 ops/s
Run 4:  60,658,837 ops/s
Run 5:  58,595,231 ops/s
Run 6:  59,376,766 ops/s
Run 7:  58,661,246 ops/s
Run 8:  58,110,953 ops/s
Run 9:  58,952,756 ops/s
Run 10: 59,331,245 ops/s

Average: 59,111,588 ops/s
Median:  59,142,000 ops/s
Stdev:   875,766 ops/s
Range:   57,772,821 - 60,658,837 ops/s
```

### Treatment: bench_random_mixed_hakmem_fast_pruned
```
Run 1:  55,339,952 ops/s
Run 2:  56,847,444 ops/s
Run 3:  58,161,283 ops/s
Run 4:  58,645,002 ops/s
Run 5:  55,615,903 ops/s
Run 6:  55,984,988 ops/s
Run 7:  56,979,027 ops/s
Run 8:  55,851,054 ops/s
Run 9:  57,196,418 ops/s
Run 10: 56,529,372 ops/s

Average: 56,715,044 ops/s
Median:  56,688,408 ops/s
Stdev:   1,082,600 ops/s
Range:   55,339,952 - 58,645,002 ops/s
```

### Performance Delta
- **Average Change**: -4.05% ❌
- **Median Change**: -4.15% ❌
- **GO Threshold**: +2.0%
- **Verdict**: NO-GO (regression exceeds negative tolerance)

## Performance Counter Analysis (perf stat, 5 runs each)

### Baseline: bench_random_mixed_hakmem_minimal
```
Cycles:        1,703,775,790 (baseline)
Instructions:  3,866,028,123 (baseline)
IPC:           2.27 insns/cycle
Branches:      945,213,995
Branch-misses: 23,682,440 (2.51% of branches)
Cache-misses:  420,262
```

### Treatment: bench_random_mixed_hakmem_fast_pruned
```
Cycles:        1,608,678,889 (-5.6% vs baseline)
Instructions:  2,870,328,700 (-25.8% vs baseline) ✓
IPC:           1.78 insns/cycle (-21.6%)
Branches:      629,997,382 (-33.3% vs baseline) ✓
Branch-misses: 23,622,772 (-0.3% count, but +3.75% rate vs baseline)
Cache-misses:  501,446 (+19.3% vs baseline)
```

## Analysis

### Success: Instruction Reduction
The compile-time backend pruning achieved excellent dead code elimination:
- **-26% instruction count**: Massive reduction from 3.87B to 2.87B instructions/op
- **-33% branch count**: Reduction from 945M to 630M branches/op
- **-5.6% cycle count**: Modest cycle reduction despite heavy pruning

This confirms that LTO DCE is working correctly and removing the MID_V3 and POOL_V2 code paths.

### Failure: Throughput Regression
Despite massive code reduction, throughput regressed by -4.05%, indicating:

**Hypothesis 1: Bad I-Cache Locality**
- Treatment has fewer branches (-33%) but higher branch-miss rate (3.75% vs 2.51%)
- This suggests code layout became worse during linker optimization
- Remaining critical paths may have been scattered across memory
- Similar to Phase 62A "layout tax" pattern

**Hypothesis 2: Critical Path Changed**
- IPC dropped from 2.27 to 1.78 instructions/cycle (-21.6%)
- This indicates the CPU is less efficient at executing the pruned code
- Cache hierarchy may be stressed despite fewer instructions (confirmed: +19% cache-misses)
- Reduced instruction diversity may confuse branch prediction

**Hypothesis 3: Microarchitecture Sensitivity**
- The pruned code path may have different memory access patterns
- Allocation patterns route through different backends (all Tiny now)
- Contention on TLS caches may be higher without MID_V3 pressure relief

### Why +5-10% Didn't Materialize

The expected +5-10% gain assumed:
1. Code size reduction → I-cache improvement ✗ (layout tax negative)
2. Fewer branches → Better prediction ✗ (branch-miss rate increased)
3. Simplified dispatch logic → Reduced overhead ✗ (IPC decreased)

The Mixed workload (257-768B allocations) benefits from MID_V3's specialized TLS lane caching. By removing it, all those allocations now route through the Tiny fast path, which:
- May have reduced TLS cache efficiency
- Increases contention on shared structures
- Affects memory layout and I-cache behavior

## Related Patterns

### Phase 62A: "Layout Tax" Pattern
- Phase 62A (C7 ULTRA Alloc DepChain Trim): -0.71% regression
- Both Phases showed code size improvements but IPC/layout deterioration
- This confirms that LTO + function-level optimizations create layout tax

### Successful Similar Phases
- None found that achieved code elimination + performance gain simultaneously

## Recommendations

### Path Forward Options

**Option A: Abandon Backend Pruning (Recommended)**
- The layout tax pattern is consistent across phases
- Removing code paths without architectural restructuring doesn't help
- Focus on algorithmic improvements instead

**Option B: Research Backend Pruning + Linker Optimizations**
- Try `--gc-sections` + section reordering (Phase 18 NO-GO, but different context)
- Experiment with PGO-guided section layout
- May require significant research investment

**Option C: Profile-Guided Backend Selection**
- Instead of compile-time removal, use runtime PGO to select optimal backend
- Keep both MID_V3 and Tiny, but bias allocation based on profile
- Trade size for flexibility (likely not worth it)

## Conclusion

Phase 64 successfully implemented compile-time backend pruning and achieved 26% instruction reduction through LTO DCE. However, the strategy backfired due to layout tax and microarchitecture sensitivity, producing a -4.05% throughput regression.

This phase validates an important insight: **code elimination alone is insufficient**. Hakmem's performance depends on:
1. **Hot path efficiency** (IPC, branch prediction)
2. **Memory layout** (I-cache, D-cache)
3. **Architectural symmetry** (balanced pathways reduce contention)

Removing entire backends disrupts this balance, despite reducing instruction count.

---

**Artifacts**:
- Baseline: `bench_random_mixed_hakmem_minimal` (BENCH_MINIMAL=1)
- Treatment: `bench_random_mixed_hakmem_fast_pruned` (BENCH_MINIMAL=1 + FAST_PROFILE_FIXED=1 + FAST_PROFILE_PRUNE_BACKENDS=1)

**Next Phase**: Back to algorithm-level optimizations or investigate why IPC dropped despite simpler code.