chantier dense-HMX: avancement — ni magnitude, ni NaN, ni shape pure (value/context-spécifique)

3 hypothèses éliminées par mesure: overflow fp16 (act=9.8), NaN/Inf inputs (0), shape pure (isolation
synthétique k=4096 ne crashe pas). Op fautive = o_proj MUL_MAT q4_0 k=4096 après FLASH_ATTN_EXT.
Prochaines étapes révisées (dump-and-replay value-vs-context, instrumentation DSP log-vers-buffer).
OPLOG mis à jour (nan/inf) dans dist/lib. ql -> commit OPLOG.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

CHANTIER_HMX_DENSE.md

@@ -40,18 +40,34 @@ supprime le crash, confirmant que c'est bien un MUL_MAT HMX.
 - ℹ️ Build debug FARF dispo si besoin : `cmake -DHEXAGON_HTP_DEBUG=ON` dans le sous-build htp-vNN → active
   `FARF_HIGH=1` (logs par-matmul m/k/n), mais inutile ici faute de capture (root).
 
-## Prochaines étapes
+## Avancement (27/05, session chantier)
-1. **Isoler le k=4096** : reproduire le matmul seul, q4_0 `[4096,2560] × f32[4096,38]` (k=4096, m=2560, n=38),
+Hypothèses **éliminées** par mesure (OPLOG + isolation) :
-   via test-backend-ops (ajouter le cas) ou un petit harness type `dual_ctx`. Confirmer le crash hors modèle.
+- ❌ Overflow fp16 d'entrée : activation du matmul fautif amax=**9.8** (≪ 65504). Clamp ±65504 = sans effet.
-   Tester k=4096 avec n et m variés pour cerner si c'est k=4096 seul ou la combinaison.
+- ❌ Overflow d'accumulation : scaling ÷32 puis ÷256 (×S en sortie) = sans effet.
-2. **Comparer k=4096 vs k=2560** dans `hmx_matmul_q_f32` / `core_dot_chunk_fp16` (hmx-matmul-ops.c) :
+- ❌ NaN/Inf dans les inputs : instrumentation `nan=0 inf=0` sur tous les ops avant le crash (le `amax` initial
-   - le VTCM chunking `hmx_compute_chunks` (taille des tuiles pour 128 dot-tiles vs 80),
+  ratait les NaN car `v>amax` est faux sur NaN ; corrigé pour les détecter → toujours 0).
-   - la boucle k par blocs de 32 et le `range = 2048*k_block - 1` (déborde-t-il un champ 16 bits cumulé ?),
+- ❌ Shape pure : le matmul isolé (test-backend-ops, q4_0 k=4096 n=38/512/16 m=2560, **données synthétiques**)
-   - le staging poids dequant (`dequantize_x4x2_weight_chunk_to_fp16_tiles`) et la taille `vec_dot_size = k*2`
+  **ne crashe PAS** sur HTP (finit, finite). Donc ce n'est pas la shape seule.
-     (8192 o/row pour k=4096) vs le budget VTCM → débordement d'index/buffer probable à 128 dot-tiles.
+**Op fautive confirmée** : le **o_proj** `MUL_MAT q4_0 [4096,2560] × f32[4096,38]` (k=4096) juste après FLASH_ATTN_EXT
-3. **Fix** : corriger le tiling/staging pour k=4096 (gate oracle = test-backend-ops -o MUL_MAT, mais ⚠ ce test a
+(en OPBATCH=1, le flush de ce matmul survient juste après le log de l'ADD suivant → crash). Inputs propres.
-   des FAIL `CPU=nan` PRÉ-EXISTANTS sur les petits q4_0 — comparer au baseline, ne pas s'y fier aveuglément).
+**Conclusion** : crash **value/context-spécifique** — un pattern de valeurs réelles (non reproduit par du random
-   Fallback acceptable si le fix est trop lourd : gater le HMX pour k≥4096 → HVX (comme le gate SSM_CONV n_t>1).
+synthétique), OU un état de contexte/VTCM/session hérité des ops précédentes (FA), qui fait fauter le MAC HMX.
+
+## Prochaines étapes (révisées après l'avancement ci-dessus)
+1. **Dump-and-replay** (tranche value-vs-context) : capturer la vraie activation `[4096,38]` + le poids q4_0
+   du o_proj fautif (CPU-side dans `enqueue_op`, écrire en fichier), puis rejouer EXACTEMENT ces octets dans un
+   harness qui lance `hmx_matmul_q_f32` sur HTP. Crash en replay → **value-pattern** (pattern de bits précis
+   qui faute le MAC/dequant) ; pas de crash → **context/état** (VTCM/session de la séquence d'ops, ex. FA avant).
+2. **Si value-pattern** : trouver l'octet/valeur déclencheur (bisection sur les lignes de l'activation), inspecter
+   le dequant q4_0→fp16 (`dequantize_x4x2_*`) et le MAC (`core_dot_chunk_fp16`, `Q6_mxmem_*`) sur ce pattern.
+3. **Si context** : instrumenter l'état VTCM/session avant le matmul (reset explicite entre ops ? interaction FA→matmul).
+4. **Instrumentation DSP** (si nécessaire, FARF bloqué sans root) : ajouter dans le skel un **log-vers-buffer-hôte**
+   (écrire diagnostics dans une zone VTCM/DDR que le CPU relit) — contourne l'absence de capture FARF.
+5. **Fallback pragmatique** si le fix est trop lourd : gater le HMX pour cette classe de matmul → HVX (comme le
+   gate SSM_CONV). Mais le dense est déjà 100% HVX (USE_HMX=0) côté JNI, donc le fallback = statu quo.
+
+⚠ L'oracle `test-backend-ops -o MUL_MAT` a des FAIL `CPU=nan` PRÉ-EXISTANTS (réf CPU NaN sur petits q4_0) — non
+fiable comme gate ; valider par la cohérence de génération + l'absence de crash, pas par cet oracle.
 
 ## État
 **Non-bloquant** : le dense tourne déjà sur HTP en **HVX** (~40 prefill, stable, cohérent) via le routage

ql

@@ -1 +1 @@
-Subproject commit 7d4caded58f8eb0d99035d7215647821e0feb1bf
+Subproject commit 5e054eed6ae3eff3bc5c45f7a12a6edc1daf0872