Replace O(N) recursive sequence_map_inverse with O(1) pack expansion

[tenpercent]

Summary

Replace the O(N) recursive sequence_map_inverse implementation with O(1) template depth using pack expansion.

Approach

• Use constexpr loop in find_source_index to locate permutation inverse indices
• Expand via pack expansion for O(1) template instantiation depth

Why It Works

Template recursion requires N template instantiations for N iterations, each with its own overhead. Constexpr loops execute within a single template instantiation, avoiding per-instantiation overhead.

Build Performance Impact

Template Instantiation Reduction (measured on device_grouped_conv3d_fwd_bias_bnorm_clamp_instance target, 248 files):

• Baseline: 7,748,880 total instantiations
• PR Replace O(N) recursive sequence_map_inverse with O(1) pack expansion #3596: 7,621,984 total instantiations
• Improvement: -126,896 instantiations (1.6% reduction)

This confirms the optimization successfully reduces template instantiation overhead by eliminating recursive template patterns in favor of pack expansion.

Test Plan

• Existing SequenceMapInverse.InverseMap and SequenceMapInverse.InverseIdentityMap tests validate correctness
• CI

Notes

• sequence_merge optimization removed from this PR (handled in Optimize sequence_gen and uniform_sequence_gen to reduce template instantiation depth #3585)
• Callers validate input via is_valid_sequence_map before calling sequence_map_inverse

[Copilot]

Pull request overview

This PR optimizes sequence_map_inverse by replacing O(N) recursive template instantiation with O(1) template depth using pack expansion and constexpr loops, reducing compilation overhead.

Changes:

• Replaced recursive sequence_map_inverse_impl with ConstexprArray and constexpr loop-based find_inverse
• Added detailed comments explaining the compilation performance benefits
• Achieved 1.6% reduction in template instantiations (126,896 fewer instantiations)

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The return value -1 for an invalid permutation is misleading since index_t is likely unsigned. Consider using a static_assert or explicit error handling to catch invalid permutations at compile-time, or document that this path should never execute for valid inputs.

Suggested change

	return -1; // should not reach for valid permutation
	return static_cast<index_t>(-1); // should not reach for valid permutation

[shumway]

I think we want to remove the O(N^2) loop and probably add memoization, too.

[shumway]

Can we make this a compile-time error, just to catch anything that is really broken?

The two patterns I know are to use a static_assert or to call a consteval function that throws an error. We don't want to have this logic silently fail.

[shumway]

This looks like we have an O(N^2) evaluation of the permutation inverse. That's much better than a recursive template instantiation, but we can probably be faster:

1. Write a direct permutation inverse:

template <index_t... Positions>
static constexpr auto compute(Sequence<Positions...>)
{
    // Build result array in one pass
    detail::ConstexprArray<index_t, sizeof...(Is)> result = {};
    index_t pos = 0;
    ((result[values[pos++]] = Positions), ...); // fold expression
    
    return Sequence<result[Positions]...>{};
}

2. Maybe use also static constexpr templated variable to cache the inverted permutations?

[tenpercent]

Looking into the instantiation patterns for a conv device instances target, I see the maximum sequence length is 9 and all of them are valid permutations.

There are 12 unique instances. Most of them are identity permutations. Maybe we can start with a shortcut for inverting identity and rolling back the separate array struct, doesn't seem worth the introduced maintenance complexity and the constant factor effect may be worse than the overhead of local small arrays

[cgmillette]

Does this handle repeated indices?