Factorization graph ~2x larger than a reference compiler's for elasticity_p1 (non-AD form) -- likely broader than the HyperElasticity case

[garth-wells]

Summary

elasticity_p1 (plain isotropic linear elasticity, P1 tet, no automatic differentiation) still runs ~1.20x slower than a reference compiler's equivalent generated kernel after landing the codegen-backend fixes in #862 and #863. Disassembly with line-level attribution (gcc -g + objdump -dl) shows this gap is not in the tensor-accumulation loop -- that's now smaller than the reference kernel's (128 vs 157 tagged instructions) and both compilers fail to vectorise it identically (-fopt-info-vec: "complicated access pattern" on both sides, an inherent property of scattering several 3-term sums into runtime-computed matrix offsets, not an FFCx-specific weakness).

The gap is upstream, in the Jacobian/metric-tensor setup phase that runs before the accumulation loop: FFCx's generated code declares 388 distinct scalar temporaries there; the reference compiler's needs only 193 -- almost exactly double, for the identical mathematical problem. Checked for the obvious explanation (duplicate/redundant expressions, the same class of bug fixed in licm() for #863) and found none: all 388 are structurally distinct expressions, not redundant computation of the same value.

Why this matters beyond elasticity_p1

This is the same class of gap already noted for HyperElasticity (a form built via ufl.derivative, i.e. automatic differentiation) elsewhere in this survey, where FFCx's factorization graph was found to be ~5.6x larger than the reference compiler's for the identical kernel. That was plausibly attributed to AD introducing extra structure. Seeing an equivalent gap on elasticity_p1 -- a plain, hand-written bilinear form with no AD anywhere in it -- suggests the underlying cause is broader: FFCx's IR-level factorization (ffcx/ir/analysis) likely isn't recognising algebraic structure in bilinear forms that couple multiple tensor/vector components through more than one material parameter (here, the Lame parameters lambda and mu), where the reference compiler's factorization does.

Why this needs its own investigation

Every fix landed this session (#861, #862, #863) was a codegen-backend rewrite: same IR in, fewer or cheaper instructions out, each bounded and independently verifiable by disassembly/instruction-count/benchmark. This is different in kind -- it's a question of whether the factorization stage that builds the expression graph before codegen ever runs could represent the same computation with far fewer distinct scalars, by recognising decomposable structure (e.g. that the elasticity tensor's action can be written as a sum of just a handful of lambda/mu-weighted pieces rather than requiring a bespoke scalar per matrix entry). That's a change to how ffcx/ir/analysis builds and CSEs its graph, not a local, mechanical rewrite -- materially larger in scope and risk than anything in #861-#863.

Suggested next step

Scope a follow-up investigation into ffcx/ir/analysis's factorization/CSE logic, starting from a side-by-side comparison of the expression graph FFCx builds for elasticity_p1 against what a reference compiler builds for the same form, to identify concretely which algebraic structure is or isn't being exploited.

Full writeup, benchmark numbers, and the codegen-backend fixes referenced above: see the linked report.

[garth-wells]

Scoping findings

Traced this down via instrumentation of the live pipeline (no repo files modified) while compiling elasticity_p1_tet.py through ffcx.compiler.compile_ufl_objects.

Where factorization happens: ffcx/ir/integral.py (_compute_integral_ir) calls build_scalar_graph (ffcx/ir/analysis/graph.py) to fully scalarize the tensor-valued integrand, then compute_argument_factorization (ffcx/ir/analysis/factorization.py) to build the F graph codegen consumes. Scalarization itself happens in graph.py's rebuild_with_scalar_subexpressions, via ValueNumberer (valuenumbering.py) and reconstruct.py's per-node-type handlers, notably handle_index_sum.

It's not a missed-CSE bug. graph_insert() in factorization.py dedups via UFL's own structural hash/equality, and empirically, among all 500 F nodes for elasticity_p1, zero pairs share an identical repr() — every literal dedup opportunity is already being taken.

The real cause is algebraic, not literal. elasticity_p1's 9x9 (81 unique) test/trial argument-component combinations each get a genuinely distinct scalar expression, because reconstruct.py's handle_index_sum eagerly unrolls every IndexSum via Python's sum() over scalar sub-expressions with no array-valued/index-preserving intermediate (no equivalent of computing K^T·K once as a small reusable array and indexing into it, the way an index-preserving IR would). Result: 500 total F nodes (302 Product + 138 Sum, almost all binary — a near-maximally-unrolled DAG), 481 of which land in the "piecewise" (once-per-cell) partition since P1 gradients are constant on an affine tet.

Not AD-specific. elasticity_p1 has no ufl.derivative anywhere in it, so the earlier HyperElasticity factorization-size finding (there attributed to AD) is now confirmed to be a symptom of the same broader, non-AD-specific limitation in the full-scalarization architecture.

Fix scope: touches graph.py, valuenumbering.py, reconstruct.py, and factorization.py — the shared scalarize-then-factorize core used by every form FFCx compiles, not a bilinear-form-specific hook. A real fix means an index-aware/tensor-aware intermediate representation (or a pre-scalarization common-sub-tensor recognition pass) comparable in size and risk to a mature optimizing compiler's own factorization passes (sum-factorization, delta-elimination, monomial collection) — not a local, mechanical patch. A narrower option (special-casing the "arg x arg" branch of handle_product) wouldn't touch the deeper IndexSum-driven unrolling in reconstruct.py, which is where most of the blow-up actually originates.

No existing mechanism to extend. optimizer.py's licm() (used for the codegen-backend fixes in #862/#863) operates on already-scalarized C-level statements, after all index structure is gone — it can't see or exploit what's been discarded upstream. This would be a new algorithm, not an extension of licm().

Given the scope (core pipeline, every form, comparable to a compiler-optimization-pass-sized undertaking) and risk (broad regression surface), this is being left as a scoped, documented investigation rather than attempted immediately. Full report: see the linked artifact in the issue description.

[garth-wells]

Design sketch, grounded in how a reference compiler actually solves this

A reference form compiler and its IR are readable as source in this environment, so I studied the real thing instead of reasoning about it in the abstract. This meaningfully narrows the scope from the previous comment's "comparable to building a whole new IR" assessment.

The key finding: the raw material is already there, one step upstream of where it's discarded

ffcx/analysis.py:127 already runs every integrand through UFL's own apply_algebra_lowering(), which expresses e.g. inner(sigma(u), grad(v)) in UFL's native index notation: ufl.classes.IndexSum, Indexed, ComponentTensor, MultiIndex/Index — each node already carrying its free indices and their dimensions (ufl_free_indices, ufl_index_dimensions).

This is the same algebraic vocabulary the reference compiler's IR uses. Its UFL-to-IR translation layer maps this UFL index-DAG onto its own IR essentially 1:1 — one IR IndexSum node per UFL IndexSum node, index threaded through, no expansion.

FFCx's own ffcx/ir/analysis/reconstruct.py runs one step later, on the exact same kind of UFL node — and instead of a one-line wrap, its handle_index_sum Cartesian-expands every surviving component combination via ufl.permutation.compute_indices(), then does results = [sum(sop) for sop in sops]: plain Python sum() over already-fully-scalarized operands, once per component.

The eager scalarization is a choice FFCx's own pipeline makes a step after the index-preserving representation was already available — not an inherent limitation of what UFL hands it.

What an index-preserving IR does differently, concretely

• Indexed(aggregate, multiindex) lets a small array-valued expression (e.g. K^T K) be computed once and referenced by many index combinations as ONE node; its dual ComponentTensor(expression, multiindex) builds an array-valued node from a scalar formula without materializing every entry. A 3x3 Jacobian contraction becomes a constant handful of nodes regardless of dimension, vs. FFCx's one distinct scalar node per (i,j) pair.
• The reference IR also folds structurally-equal subgraphs together on construction (a node-equality check reassigns shared children on a match) — a cheap, always-on CSE, roughly comparable to what FFCx's value-numbering already does. But the >2x node-count gap comes overwhelmingly from never expanding in the first place, not from smarter after-the-fact CSE.
• The reference compiler's more advanced factoring (monomial collection, plus a combinatorial common-atomic-factor search adapted from an established optimizing-compiler technique) is real and valuable but is a second win layered on an already-compact representation — not what's closing the specific gap measured here.
• Final lowering to code is mostly real nested loops (an imperative-AST-style lowering, with a For-node representation), with a deliberate, tunable selective unrolling pass gated by an extent threshold, applied only to small, cheap contractions — larger loops (quadrature points, basis functions) stay as loops.

Revised minimal path (decreasing disruption)

1. Stop scalarizing at graph-build time. Skip rebuild_with_scalar_subexpressions's Cartesian expansion; build the ExpressionGraph directly over the post-apply_algebra_lowering UFL DAG, keeping IndexSum/Indexed/ComponentTensor nodes intact. Largely removal, not new machinery.
2. valuenumbering.py gets simpler, not more complex — a compact, non-expanded graph removes the "symbols per component" bookkeeping the current per-terminal special-casing exists to handle.
3. factorization.py is the real engineering lift. It currently groups terms by argument-dependence assuming fully-scalarized per-component nodes; adapting handle_sum/handle_product to group while some indices are still symbolic is the hard part, and the reference compiler's monomial-collection/atomic-factoring passes are a concrete template.
4. Add a late, selective unrolling pass before code generation (the reference IR's own componenttensor-removal/delta-replacement/index-sum-unrolling passes as templates), producing the same flat scalar statements FFCx's codegen already expects — the least risky integration point, deferring the "real loops vs. unrolled" question rather than forcing it up front.

Open questions before implementation

• How disruptive would index-preserving intermediates be for FFCx's downstream codegen (ffcx/codegeneration/), which currently assumes flat per-quadrature-point scalar assignments? Not traced in this pass.
• Does FFCx's handling of symmetric tensor spaces (ufl.pullback.SymmetricPullback, referenced in valuenumbering.py) depend on today's eager expansion for correctness? Also not verified.

Full report (including where this fits in the broader survey): see the linked artifact.

[garth-wells]

Implementation attempt: a narrower shortcut, and why it doesn't work

Tried a scoped-down version of the design sketch before committing to the full index-preserving redesign: rather than changing representation throughout the pipeline (graph.py/valuenumbering.py/reconstruct.py/factorization.py), detect the specific "dense n0 x n1 grid of products from two small factor sets" pattern directly in the already-scalarized flat statement list (in ffcx/codegeneration/integral_generator.py's generate_partition), and replace it with two small arrays + one tight nested loop, entirely within the codegen backend.

Branch: garth/index-preserving-factorization (kept, unmerged, as a documented negative result).

It's correct. 212/212 tests pass, including several that initially caught a real bug: statements later in the same partition can already reference a about-to-be-folded symbol by name (e.g. an index-sum accumulation combining several quadrature/index-sum contributions into one argkey), so removing a declaration requires substituting that reference too, not just updating the external UFL-expression-to-access mapping (which only affects lookups made after the pass runs — anything built earlier in the same generate_partition call has already baked the old symbol into its expression tree).

But it measurably regresses performance. GCC 14.2, -O3 -march=native -mprefer-vector-width=512 -ffp-contract=fast, both in isolation (plain main: 3173 → 3235 instructions for elasticity_p1's bilinear kernel) and combined with every codegen fix already landed this session (#861/#862/#863: 1511 → 1628 instructions) — worse both times. Runtime confirms it: poisson_p1 and elasticity_p1 both regress ~10%, reproducibly across two repeated benchmark runs, with this pass enabled on top of the already-landed fixes.

Working hypothesis for why: GCC's own SLP vectorizer and register allocator already do a good job on the flat scalar code once the loop-fusion/dedup/weight-fusion fixes are in place. Introducing a real memory-backed array plus explicit loop control for what are, in absolute terms, very small extents (single or low double digits) adds overhead — array declarations, index arithmetic, weaker optimizer assumptions around array accesses versus named scalars — that isn't recovered for grids this small.

This doesn't invalidate the broader design sketch. A real index-preserving fix changes representation before scalarization ever happens, so the factorization stage itself only ever builds ~n0+n1 nodes instead of n0×n1, and lets the codegen backend choose how (and whether) to loop-ify from a genuinely smaller representation. What this rules out is the narrower shortcut of retrofitting array structure onto already-scalarized code after the fact — that specific approach is a dead end, and it's now documented as one rather than left for a future attempt to rediscover.

[garth-wells]

Re-measured on current main + #861/#862/#863: the elasticity_p1 gap this issue was opened for is mostly closed already

Before attempting the index-preserving IR redesign sketched above, I hand-tested the premise directly: compiled elasticity_p1_tet's bilinear form fresh from garth/full-stack-bench (base main + #861 + #862 + #863, i.e. everything already landed this session), disassembled it against a reference compiler's generated kernel for the identical form (on disk from earlier benchmarking), and re-ran the timing harness.

Two corrections to the earlier scoping comments on this issue:

1. The "388 vs 193 scalar temporaries" comparison conflated declared C-variable count with real work. Counting actual arithmetic operators (+,-,*,/) in the setup phase of each generated kernel: FFCx ~424 ops, reference ~454 ops — FFCx does slightly fewer, not roughly double. FFCx's code is just broken into more, finer-grained named temporaries per operation (a consequence of reconstruct.py's binary-only Sum/Product handlers), not doing more redundant algebra. Disassembling both with gcc-14 -O2 -g + objdump -dl and counting real machine instructions confirms this: 1665 total instructions for FFCx's kernel vs 1594 for the reference's — a ~4.5% gap, not 2x.

2. The runtime gap has already shrunk to match. Timing both kernels with the harness (-O2, gcc-14), repeated twice for stability:

   • FFCx (current main + Wire up reciprocal-CSE, and fold power-of-two round-trips #861-863): 160.7ns, 168.4ns (two runs)
   • reference: 158.7ns, 157.3ns

   That's a ~1.01x-1.07x gap now, down from the ~1.20x that motivated opening this issue. The codegen-level fixes already landed this session (weight/quadrature-scale fusion, licm() loop-fusion and cross-group dedup, reciprocal/pow2 CSE) evidently absorbed most of what used to show up as this gap, even though they were written without this issue's factorization-graph finding in mind.

Conclusion: the factorization-graph size difference (500 F-nodes vs the reference's fewer, still real at the IR level) no longer translates into a meaningful runtime difference for elasticity_p1, given the codegen-side fixes already in place. Investing in the full index-preserving IR redesign (touching graph.py/valuenumbering.py/reconstruct.py/factorization.py, shared by every form) to close an already-~5% gap is a poor risk/reward trade — especially given the previous attempt at a narrower version of this idea (comment above) measured a regression, not an improvement.

This doesn't mean the IR-level factorization-graph-size finding is wrong or worthless — it may still matter for forms with a worse starting ratio (HyperElasticity's 5.6x node-count gap was never re-measured at the runtime level this session) or for FFCx's own compile-time performance on large forms. But for the specific motivating case, the cheap codegen-level path already closed most of the gap. Recommend leaving the IR redesign unattempted unless a form surfaces where the runtime gap (not just node count) is still large after the current fixes.

[garth-wells]

Re-ran the same hand-test on HyperElasticity's Jacobian — this gap is real, current, and unaffected by #861-863

Following up on the elasticity_p1 re-measurement above (which found that gap had closed to ~1.05x): repeated the identical methodology — fresh compile from garth/full-stack-bench (main + #861 + #862 + #863), disassemble against a reference compiler's generated kernel, count instructions, time both — for HyperElasticity's Jacobian (a_J) cell integral, the specific kernel §6 originally flagged with a 5.6x larger factorization graph.

Unlike elasticity_p1, this gap hasn't moved:

• Scalar temporaries: 3619 (FFCx, current) vs 616 (reference) — 5.9x, matching the original 3470-vs-616 (5.6x) almost exactly. None of Wire up reciprocal-CSE, and fold power-of-two round-trips #861-863 touch this (they're codegen-backend passes; this gap originates in ffcx/ir/analysis's factorization stage, which they don't touch).
• Machine instructions (gcc-14 -O2 -g + objdump -d, standalone compiled kernel): 7323 (FFCx) vs 5952 (reference) — 1.23x.
• Runtime (-O2, the flag DOLFINx JIT-compiles with by default), two repeated runs: FFCx 3.33ms/3.37ms vs reference 2.55ms/2.57ms — ~1.30x, consistent with the original ~1.32x measurement.
• Under -O3 -ffast-math -march=native: 2.10ms/2.11ms (FFCx) vs 1.94ms/1.95ms (reference) — ~1.08-1.09x FFCx slower, which does not reproduce the original report's finding of a flip to 0.85x (FFCx faster) under the same flags. Given §9's documented, undiagnosed instability on this same benchmark host, I'd treat that specific flip as suspect rather than conclude fast-math behavior changed — but the -O2 number, which matches the original almost exactly across two measurement sessions, is solid.

Conclusion: this is the gap worth pursuing. It's real, reproducible, unaffected by anything landed this session, and concentrated in the practical -O2 default DOLFINx actually uses. Unlike elasticity_p1 — where the codegen-level fixes closed the runtime gap as a side effect even though nothing touched the factorization stage — HyperElasticity's Jacobian shows no such rescue, because its 5.9x node-count gap is large enough that codegen-level cleanup (CSE, LICM, weight-fusion) can't compensate the way it did for elasticity_p1's more modest ~2x-ish redundancy.

If the index-preserving IR redesign (§15) is ever attempted, this is the form to verify against, not elasticity_p1 — and worth checking whether the gap is derivative()-specific (the likely culprit per §6, since this is the one AD-generated form in the survey) before assuming the general-purpose redesign is the only path; a narrower fix targeting how UFL's derivative() output gets factorized might be lower-risk and sufficient if the gap turns out to be concentrated there specifically.

[garth-wells]

Checked whether the HyperElasticity gap is derivative()-specific — it isn't, but the finding is more precise than "build the general redesign"

Following the previous two comments (elasticity_p1's gap closed already; HyperElasticity's hasn't), the natural next question: is HyperElasticity's 5.9x blowup something peculiar to how ufl.derivative() expands the chain rule, or the same generic mechanism at work on denser input? This matters because a derivative()-specific redundancy would be a much narrower, lower-risk fix than the general index-preserving redesign in §15.

Measured directly, comparing the fully-preprocessed UFL integrand (post apply_algebra_lowering+apply_derivatives, i.e. exactly what ffcx/ir/analysis receives) through each pipeline stage, for HyperElasticity's Jacobian cell integral vs. elasticity_p1's hand-written bilinear form:

stage	elasticity_p1 (hand-written)	HyperElasticity a_J (derivative())
preprocessed UFL DAG nodes	134	389
→ S-graph (fully scalarized)	219 (1.63x)	1460 (3.75x)
→ F-graph (argument-factored)	502 (2.29x)	3533 (2.42x)
distinct F-node expressions	502 of 502 (zero dupes)	3533 of 3533 (zero dupes)

Three things fall out of this:

1. The derivative()-produced UFL DAG is not anomalous. 389 nodes, mostly ComponentTensor/IndexSum/Indexed (58% of nodes) — denser than elasticity_p1's 45%, but the same kind of structure, not something malformed or redundant in itself. apply_derivatives is doing its job correctly; the DAG it hands off is compact.

2. The disproportionate cost is concentrated in scalarization (build_scalar_graph/valuenumbering.py), not argument factorization. The F/S ratio (factorization.py's arg×arg Cartesian-product step) is nearly identical between the two forms — 2.29x vs 2.42x, scaling fine regardless of complexity. The UFL→S-graph ratio is what diverges: 1.63x vs 3.75x, more than double. This is rebuild_with_scalar_subexpressions assigning one symbol per free-index combination at every nesting level — for a shallow, single-level index structure (grad(v)[i,j]) this is cheap; for a deeply nested composition (W(Q(Ef(E(C(F))))), six levels of tensor operations chained by derivative()'s mechanical differentiation) the per-level expansions compound through the nesting depth rather than adding.

3. Zero duplicate F-node expressions in either form (structural-equality check via repr()) — confirms, a second time on a different form, that there's no missed literal CSE anywhere in this pipeline. Every one of the 3533 nodes is genuinely distinct under the current architecture.

Conclusion: this isn't derivative()-specific in the sense of "chain rule expansion produces avoidable duplication" — there's no narrow patch targeting derivative()'s output specifically. But it is more precise than "rebuild the whole scalarize-then-factorize core": the disproportionate growth is concentrated in scalarization's handling of nesting depth, not in argument factorization (which the data shows scales proportionally fine, and wouldn't need the invasive rework §15 worried about). derivative() doesn't create a special case, it's just a reliable way to produce deep index nesting (any hand-written form composing several nonlinear tensor operations — a plasticity or viscoelastic model, say — would hit the same wall).

If this is picked up, the highest-leverage, most targeted version of §15's redesign is narrower than originally scoped: fix nested-index scalarization in valuenumbering.py/reconstruct.py first (skip re-flattening an already-scalarized inner ComponentTensor/IndexSum result at each outer nesting level) and leave factorization.py's argument-grouping mostly alone, since it isn't where the disproportionate cost lives. That's a smaller, more contained change than touching all four files as originally scoped.

[garth-wells]

Checked for value-level duplicates in the S-graph (tensor-symmetry hypothesis) — mostly ruled out too

Following the previous comment (scalarization, not argument-factorization, is where HyperElasticity's disproportionate blowup lives): the remaining open question was whether that 3.75x UFL-DAG-to-S-graph expansion contains value-level duplicates that the current architecture can't see — e.g. two different free-index paths through a symmetric derivative tensor landing on the same numeric quantity via different (structurally distinct) expression trees. That would be invisible to a repr()-based structural check (already done twice, zero duplicates both times) but would still be a real, exploitable redundancy if present.

Method: numerically evaluated all 1460 S-graph node expressions for HyperElasticity's a_J cell integrand across 4 independent random trials (random values assigned per distinct leaf — modified terminals, constants — held consistent within a trial, varied across trials), and grouped nodes by their value signature across all 4 trials. A coincidental match across 4 independent random trials is practically impossible, so any group that survives is a genuine symbolic identity, not noise.

Result: 1442 distinct value-signatures out of 1460 nodes — only 36 nodes (18 pairs, ~2.5%) are true value-duplicates with differing structure. Looked at a few: they're small, incidental identities (e.g. a 1 + (...) subexpression that happens to equal a normalization term elsewhere), not a systematic pattern tied to the tensor's symmetry structure.

Conclusion: this rules out the last plausible "cheap win" hypothesis. Three independent checks this session, all negative:

1. Literal structural duplicates in the F-graph (elasticity_p1 and HyperElasticity both: zero).
2. Commutative/associative canonicalization catching missed structural equivalences (elasticity_p1, from earlier scoping: ~30/539, all cross-form not within-form).
3. Value-level duplicates in the S-graph from tensor symmetry or other semantic identities (HyperElasticity: ~2.5%, not systematic).

The 3.75x scalarization expansion is not hiding missed CSE of any kind — literal, commutative, or semantic. It's genuinely necessary volume: flattening HyperElasticity's nested tensor composition into scalars really does require that many distinct values. There's no shortcut left that avoids touching how scalarization represents nested index structure; the only remaining lever is deferring it (the index-preserving approach in §15/§19), not finding a smarter way to deduplicate after the fact.

This closes out the "is there a cheap fix" line of investigation for this issue. The scoped fix (target valuenumbering.py/reconstruct.py's nested-index handling specifically, per the previous comment, not the fully general four-file rewrite) remains the only path forward if this is picked up — genuinely a real, moderately-sized implementation, not a quick patch.

[garth-wells]

Scoped a full written plan, then Milestone 0 (the gating experiment) came back negative -- stopping here

Following up after the last round of checks on this issue: given every "cheap dedup" avenue was exhausted, the next step was to scope the real fix (deferring scalarization so an array-shaped computation is represented once instead of re-expanded per index combination) as a proper written plan before touching any code, given the size and shared-pipeline risk.

Two research passes (one tracing the actual F-graph-to-C-statement codegen path, one design-reviewing the array-valued-node approach against every special case in valuenumbering.py/factorization.py) reframed the plan usefully: the two things a redesign could achieve are separable --

• Goal A (shrink FFCx's own factorization-graph size / compile time) genuinely needs array-valued S/F-graph nodes -- a large, invasive change to a data model several special cases depend on (SymmetricPullback dedup, modified-terminal derivative/restriction dedup, Conditional/Conj handling), and it also turned out codegen has a hard assertion rejecting non-scalar factors (ffcx/codegeneration/integral_generator.py: raise RuntimeError("Code generation for non-scalar integrals unsupported") if a block has more than one scalar factor) -- so this touches codegen just as much as the IR analysis files.
• Goal B (faster generated C at -O2, the thing actually motivating this issue) only needs the emitted C to contain a loop instead of N unrolled statements for a provenance-related run of scalars -- it doesn't need the S/F graph's node-per-scalar invariant to change at all.

The plan pursued Goal B first, via a cheap gating experiment before writing any IR code (Milestone 0): hand-edit the actual generated kernel for HyperElasticity's Jacobian (a_J) cell integral, replacing its real redundancy pattern (82 distinct pre-scale values each multiplying one shared per-quadrature-point weight -- fw_i = sp_i * weight[iq], not the "dense two-factor grid" the earlier rejected shortcut targeted) with a genuine C array + tight loop, compile both at -O2, and measure.

Result: negative, cleanly. Verified bit-exact numerically identical output (max abs diff 0.0 against a newly-added golden-master fixture -- see below) but measured 2.7-4.4% slower, reproducibly across two repeated runs, with slightly more static instructions (7536 vs 7464). Same direction as the earlier rejected shortcut, now confirmed on the form's actual redundancy shape (linear, N=82) rather than the two-factor-grid shape that shortcut targeted -- and at a much larger N than the elasticity_p1 case that first showed this. GCC's flat scalar code at -O2 handles this well regardless of pattern shape or scale; introducing real array+loop control doesn't recover its own overhead here either.

Per the plan's explicit decision point, stopping here. No IR change is justified by this result. This is now the second, independent confirmation (different pattern shape, different form, larger scale) that "give codegen a loop instead of unrolled statements" isn't a win for these kernels at -O2 -- the earlier f6494aad branch and this result together make a reasonably strong case that this whole class of fix (loop-ify a redundant-looking flat statement run, regardless of where in the pipeline the decision is made) isn't where FFCx's remaining gap on this form actually gets closed, if it's closable at all through codegen-shape changes rather than genuinely reducing scalarization's node count (Goal A, which remains unexplored and would need to be justified on its own compile-time merits, not on a runtime win that doesn't appear to exist).

What's landing regardless of this result: a golden-master numeric regression test for HyperElasticity's cell kernels (PR #867) -- this form had zero numeric correctness coverage before (only a "does it compile" check), and it's the fixture this entire investigation has been anchored to.

Recommend leaving this issue open but not actively pursued further without a new angle -- the cheap paths are now exhausted (five independent negative checks across two sessions of work), and Goal A's compile-time-only payoff hasn't been asked for by anyone yet.