Should we keep the HECO-style optimization passes?

[j2kun]

Placeholder for TODO and discussion.

[AlexanderViand]

I'd vote for no, at least not the current unroll-everything version - maybe a "smart" version that instead looks at affine loops might still make sense (especially if the "smart" version turns out to just be a few calls to ISL)...

Independent of that, some of the patterns might make sense to keep around just as general peephole optimization?

[j2kun]

Looks like we'll need to keep it for a while longer, most of our tests that do naive loops that came from HECO don't work when the HECO passes are removed

https://github.com/j2kun/heir/pull/new/remove-heco-from-pipeline was the attempt.

[j2kun]

we could potentially migrate all those tests to use linalg ops, and then ensure the linalg ops have kernels, but then the frontend tests that involve naive loops would also fail, so I think maybe we wait until we have proper loop support.

[github-actions]

This issue has 1 outstanding TODOs:

• lib/Pipelines/ArithmeticPipelineRegistration.cpp:203: figure out where this fits in the new pipeline

This comment was autogenerated by todo-backlinks