[CoreML EP] Add Identity, Ceil, Tile builders + drop trivial-only partitions

[maxwbuckley]

Description

Adds three MLProgram op builders (Identity, Ceil, Tile) to the CoreML EP and a partition-quality heuristic that drops CoreML partitions consisting entirely of trivial shape / cheap-elementwise ops.

No tracking issue; discovered via YOLOv10 partitioning analysis on Apple Silicon.

Empirical impact

YOLOv10n, M3 Max, MLProgram, batch 1, 1500-iter pooled:

	Partitions	Mean	StdDev	P99
Without this patch	4	3.798 ms	0.867	6.608
With this patch	3	3.403 ms	0.636	5.957

10.4% mean speedup, 26% stddev tightening.

Why both pieces are coupled

Adding the builders alone is net-negative on graphs where these ops sit in isolated chains. Per-op CoreML dispatch overhead on M3 Max (32-op chains on a 1×64×56×56 fp32 tensor, n=2997, MLProgram):

op	CPU EP per op	CoreML EP per op
Identity	<1 µs	~14 µs
Ceil	~6 µs	~12 µs
Tile	~10 µs	~10 µs

A trivial-only partition pays ~50-100 µs round-trip marshalling plus ~10 µs per op of CoreML dispatch, vs <1 µs each on CPU. Worth claiming only when sandwiched between compute-heavy ops, where the round-trip is already paid for. The heuristic enforces that.

Implementation

New op builders. Identity emits MIL identity (NN path uses LINEAR(α=1, β=0)). Ceil joins the existing unary chain in UnaryOpBuilder. Tile emits MIL tile; it overrides HasSupportedInputsImpl to additionally accept INT32/INT64/BOOL (Tile is shape-only data movement, so the default float-only filter rejected it on common YOLO grid-index post-processing) and accepts a runtime reps tensor in addition to a constant initializer.

Heuristic. CoreMLExecutionProvider::GetCapability now uses the callback-taking overload of CreateSupportedPartitions (same as NNAPI EP). A partition is kept iff at least one node is outside the trivial set:

{Identity, Cast, Reshape, Squeeze, Unsqueeze, Flatten, Transpose, Tile, Ceil}

This lets the new builders absorb mid-chain trivial ops into existing CoreML partitions (the win) without claiming isolated trivial chains that would force a needless CPU→CoreML→CPU detour (the regression).

Tests

coreml_basic_test.cc covers both halves of the heuristic.

Builder coverage (compute anchor present → claimed):

• IdentityWithConvAnchor, CeilWithConvAnchor, TileWithConvAnchor

Heuristic coverage:

• ConvTrivialChainConvKeepsAllOnCoreML — Conv → Identity → Cast → Reshape → Conv stays in a single CoreML partition
• TrivialOnlyChainIsNotClaimedByCoreML, ReshapeOnlyChainIsNotClaimedByCoreML, TransposeOnlyChainIsNotClaimedByCoreML, TileOnlyIsNotClaimedByCoreML, CeilOnlyIsNotClaimedByCoreML, MixedTrivialChainIsNotClaimedByCoreML — each falls back to CPU

Trivial-only tests pin graph_optimization_level = Default so passes like IdentityElimination / CastElimination cannot pre-empt the heuristic - what's exercised is GetCapability itself.

All 28 CoreML EP tests pass locally on macOS 26.3 / M3 Max.

🤖 Generated with Claude Code

[maxwbuckley]

@yuslepukhin last one 🥳

[yuslepukhin]

Some minor comments.

Coverage gaps:

• No test for Tile with non-unit repeats (e.g., reps=[1,1,2,2]) — would be good to verify actual tiling works on macOS.
• No test for Identity/Tile on non-float types (int32, bool) — though the builders' type restrictions make this less relevant.
• No standalone test for the NeuralNetwork path of Identity or Tile builders (only MLProgram is tested). The - NeuralNetwork path exists in both builders but RunConvChainTest uses MakeCoreMLExecutionProvider("MLProgram").
• The tile_with_repeats parameter in MakeConvWithTrivialChainModel is accepted but unused ((void)tile_with_repeats;). This is dead code — it was likely meant to support a variant test but was never wired up.

[yuslepukhin]

No C casts. Use ORT_UNUSED_* macros