Add eager_inline() directive for schedule-time inlining

[alexreinking]

This PR adds a scheduling directive, g.eager_inline({f1, ..., fN}) that immediately and destructively inlines the bodies of f1, ..., fN into g. This happens in sequence so that direct calls to f_j by f_i, i < j can be inlined without needing to issue the directive multiple times.

I'm placing this on the bottom of the stack because it is the easiest to review.

Breaking changes

None. This is a new directive.

Checklist

• Tests added or updated (not required for docs, CI config, or typo fixes)
• Documentation updated (if public API changed)
• Python bindings updated (if public API changed)
• Commits include AI attribution where applicable (see Code of Conduct)

---

_{Stack created with GitHub Stacks CLI • Give Feedback 💬}

[codecov]

Codecov Report

❌ Patch coverage is 64.70588% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 70.24%. Comparing base (ceea694) to head (fc9374c).
⚠️ Report is 4 commits behind head on main.

Files with missing lines	Patch %	Lines
src/Func.cpp	57.14%	4 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #9256      +/-   ##
==========================================
- Coverage   70.26%   70.24%   -0.03%     
==========================================
  Files         257      257              
  Lines       79106    79122      +16     
  Branches    18954    18957       +3     
==========================================
- Hits        55583    55578       -5     
- Misses      17885    17895      +10     
- Partials     5638     5649      +11     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[mcourteaux]

I'd like to see an actual example (code or description) of when this is useful. I don't really grasp what it means when you say:

This is useful to surface structure that other schedule-time directives need to see.

What's now possible that otherwise is impossible?

[alexreinking]

What's now possible that otherwise is impossible?

That's in #9190 (top of the stack) — the idea is that if you have a function that looks like f(x) += g(x, r) * h(x, r) then you need to be able to look inside the definitions of g and h to find invariant factors. Say g(x, r) looks like sc_g(x) * Wg(x, r) and h has a similar form. You'd like to be able to pull the sc_g(x) * sc_h(x) factor into a write-back, but it's just not visible without inlining at a point in time that hoist_invariants can see it.

[abadams]

Let's discuss in person how this interacts with .in()/.clone_in() and how it would interact with proposed changes to .in()/.clone_in(). I think it's fine but it's worth working through.

[alexreinking]

Let's discuss in person how this interacts with .in()/.clone_in() and how it would interact with proposed changes to .in()/.clone_in(). I think it's fine but it's worth working through.

I followed up on the potential for strange interactions with .in() and .clone_in(). In short, it's fine especially since we're planning to rework .in() and .clone_in() as eager DAG rewrites soon, anyway.

If someone writes f.in().eager_inline(f), assuming f is inlinable (no update definitions), they get a normal/correct call to f, but then lose the schedule that was on f. It's a weird thing to do, but it's not pathological.

Writing f.clone_in().eager_inline(f) is a no-op because there are no calls to f.

Still, it might be worth warning or erroring if you .eager_inline(f) when there are no direct calls to f. Thoughts?