unify memory opimization passes

better reports
cleanups

.agents/invariants/PARALLELISM_AND_RUNTIME_INVARIANT.md

@@ -1,20 +0,0 @@
-# Parallelism and Runtime Invariant
-
-Compile-time optimization must not trade away execution parallelism or worsen
-theoretical runtime behavior. The absence of a precise runtime measurement does
-not make such a trade acceptable.
-
-In particular, a compile-time optimization must not:
-
-- serialize work that can execute independently;
-- coarsen lane, core, batch, or scheduling granularity in a way that reduces
-  available execution parallelism;
-- increase the theoretical runtime critical path, instruction count, memory
-  traffic, synchronization, or required copies merely to reduce compiler work;
-- merge independently scheduled work when doing so may reduce concurrency.
-
-Compiler representations may share analysis, planning, or code-generation
-work only when the emitted execution retains the same independent work,
-schedule semantics, and available parallelism. If runtime impact cannot be
-measured precisely, it must be established from the transformation's semantics;
-uncertainty is not permission to accept a possible runtime regression.

.agents/invariants/PERFORMANCE_OPTIMIZATION_INVARIANT.md

@@ -11,7 +11,6 @@ This invariant applies to:
 - deferred communication;
 - Spatial-to-PIM lowering;
 - bufferization;
-- memory coalescing;
 - liveness planning;
 - PIM code generation.
 
@@ -19,12 +18,17 @@ This invariant applies to:
 
 A compiler compile-time or memory optimization must not reduce available
 hardware parallelism or worsen theoretical execution time. In the absence of a
-precise runtime model, it is forbidden to serialize independent work, reduce
+precise runtime model, uncertainty is not permission to accept a possible
+runtime regression. It is forbidden to serialize independent work, reduce
 the number of simultaneously schedulable compute instances, replace parallel
 graph or core batches with sequential loops, introduce recomputation, add
 runtime copies, increase communication or instruction count, or lengthen the
 schedule critical path merely to reduce compiler time or memory usage.
 
+Compiler representations may share analysis, planning, or code-generation
+work only when the emitted execution retains the same independent work,
+schedule semantics, scheduling granularity, and available parallelism.
+
 An optimization is acceptable only when its static runtime proxies are equal or
 better.
 
@@ -33,6 +37,8 @@ better.
 Do not:
 
 - use fewer parallel lanes or cores to simplify IR;
+- coarsen lane, core, batch, or scheduling granularity when it may reduce
+  concurrency;
 - scalarize a valid graph or core batch;
 - replace independent operations with one sequential loop;
 - recompute values to reduce storage;