fix(Compiler/Expr): replace caseInteger list-indexing fallback with equalsInteger chain

[Unisay]

Summary

Closes IntersectMBO/plutus-private#2135.
Fixes the execution cost regression documented in #7691.

When compiling caseInteger in the default SumsOfProducts mode, the fallback used PlutusTx.List.!!, which built a linked list at runtime and indexed into it with a Z-combinator. This caused a 3-5x cost increase for unsafeFromBuiltinData on multi-constructor types.

This PR replaces the fallback with a lazy equalsInteger/ifThenElse chain in PIR.
Uses the (all dead. resTy) / (/\dead -> branch) encoding to avoid evaluating non-matching branches. No runtime allocation, no Y-combinator, no linked list.

How it works

The non-BuiltinCasing branch in Compiler/Expr.hs now generates PIR equivalent to:

ifThenElse {all dead. resTy} (equalsInteger scrut 0)
  (/\dead -> b0)
  (/\dead -> ifThenElse {all dead. resTy} (equalsInteger scrut 1)
    (/\dead -> b1)
    (/\dead -> b2)
    {resTy})
  {resTy}

Which erases to delay/force in UPLC, matching the pre-regression pattern.
The BuiltinCasing branch is unchanged (native case on the integer).

Budget comparison

data ABC = A Integer | B Integer | C Integer, same source compiled in both modes:

SumsOfProducts (default, the regressed mode)

Test	Metric	Baseline (if False)	This PR	Regressed (master)
decode A (index 0)	CPU	1,244,851	1,292,851	2,214,190
	Memory	4,662	4,962	9,964
decode C (index 2)	CPU	2,050,823	1,746,441	4,054,578
	Memory	7,468	6,366	17,974

Baseline is generated by bypassing caseInteger (if False in unsafeFromDataClause),
which falls back to the old tuple-pattern-matching TH code. The small remaining difference
(~4% for index 0) is from casePair continuation vs fst/snd let-bindings in the
pair extraction, which is inherent to the caseInteger TH code path.

BuiltinCasing (unaffected by this change)

Test	Metric	Budget
decode A (index 0)	CPU	512,582
	Memory	2,596
decode C (index 2)	CPU	677,790
	Memory	2,998

[github-actions]

Execution Budget Golden Diff

0c08eee (master) vs 7638be5

output

This comment will get updated when changes are made.

[zliu41]

This needs to be backported to the version the Hydra team is using.

[SeungheonOh]

looks good to me

[Unisay]

Update: fixed Marlowe Semantics test failures

Running the Marlowe benchmark suite (cabal run plutus-benchmark:marlowe-validators) revealed that 53 out of 206 Semantics test cases were failing with a bare error from the CEK machine. The RolePayout tests (simpler validator) passed fine.

Root cause

The bug turned out to be in compileHaskellList, not in the equalsInteger chain generation itself.

compileHaskellList handles two GHC Core representations of list literals:

1. Build form: build @ty (\con nil -> con e1 (con e2 ...)) — used when GHC can apply foldr/build fusion
2. Cons chain: (:) @ty e1 ((:) @ty e2 (... ([] @ty))) — used when GHC inlines build

The old code had a pattern for case 2 that matched (:) @ty e _, silently discarding the tail. This worked fine when the tail was [] (single-element lists), but for types with many constructors — like Marlowe's Value (12 constructors) and Observation (11) — GHC chose the cons-chain form, and the pattern returned only the first branch. The resulting equalsInteger chain had 1 branch instead of 11/12, so any constructor with index > 0 fell through to error.

The fix adds a recursive consumeCons that walks the full (:) spine.

Why this wasn't caught earlier

• The existing IsData tests use types with ≤ 3 constructors, which GHC represents in build form
• Whether GHC uses build vs (:) depends on the surrounding code context and optimizer decisions — hard to reproduce in isolation
• The bug was latent on master (the cons pattern existed before this PR), but only manifested now because our equalsInteger chain calls compileHaskellList on the SoP/Scott path, which master never did

Test results

• 838/838 plugin tests pass
• 2697/2697 plutus-core tests pass
• 0/206 Marlowe Semantics failures (was 53)
• 0/100 Marlowe RolePayout failures
• Marlowe SoP flat file is ~0.7% smaller (57266 vs 57663 bytes on master)