transforms: Add function-constant-pinning pass to specialize functions

[AntonLydike]

This adds the function-constant-pinning pass that takes annotated functions and creates specialized versions of them that pin a value to a constant.

Currently only supports pinning at the top level of a function. Also other limitations, that will be documented on a train ride soon!

See the filecheck for examples on how the pass works!

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.60%. Comparing base (4bfe7a3) to head (dc8000c).
Report is 50 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2389      +/-   ##
==========================================
- Coverage   89.79%   89.60%   -0.19%     
==========================================
  Files         354      359       +5     
  Lines       44579    45763    +1184     
  Branches     6684     6905     +221     
==========================================
+ Hits        40030    41008     +978     
- Misses       3574     3694     +120     
- Partials      975     1061      +86     

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

[superlopuh]

On one hand, the code looks ok. On the other hand, I would have preferred a slightly decomposed API. It feels like outlining the body should be separate to splitting the code on it being a constant. It feels like these could be separate Python helpers, with their own Python API, instead of a pass which seems quite specialized for a project. My understanding of MLIR and IREE is that this is a pattern that is encouraged. If it unblocks you, I think we should be ok to merge, but I'd be a tiny bit less concerned with the maintainability of this code if it were split into self-contained PRs, one of which provides and tests splitting IR based on a constant value, another one of which provides and tests outlining blocks to functions, and maybe another one that composes them into a pass.

[AntonLydike]

On one hand, the code looks ok. On the other hand, I would have preferred a slightly decomposed API. It feels like outlining the body should be separate to splitting the code on it being a constant. It feels like these could be separate Python helpers, with their own Python API, instead of a pass which seems quite specialized for a project. My understanding of MLIR and IREE is that this is a pattern that is encouraged. If it unblocks you, I think we should be ok to merge, but I'd be a tiny bit less concerned with the maintainability of this code if it were split into self-contained PRs, one of which provides and tests splitting IR based on a constant value, another one of which provides and tests outlining blocks to functions, and maybe another one that composes them into a pass.

I do understand your concerns here, I think this code will evolve over time, and I see a good chance that we yank it out again later in case we don't need it. Maybe we should put this in an experimental folder?

[superlopuh]

Oh yeah experimental would make me less hesitant for sure, then YOLO ship it