About the upstream version of MLIR

[esifea]

Hello, it appears that the HEIR project consistently merges LLVM (MLIR) from upstream.

I wonder if we can continue doing this after starting to implement MLIR dialects. Based on my experience, the MLIR project undergoes rapid changes, occasionally overlooking backward compatibility.

Certainly, I acknowledge the significance of staying up-to-date with upstream developments. Nevertheless, I would appreciate hearing others' opinions while considering the maintenance costs involved.

[j2kun]

We discussed two aspects of this in the last meeting. First was that the more solid/standardized parts of the project would be upstreamed to MLIR. Second, internally Google has an on-call rotation to fix upstream breakages of internal projects. Because HEIR has a "google-internal" source of truth, we can argue that we should be added to the list of "critical" projects to be updated (currently it is on a list of "best effort" updates).

Adding in the fact that maintaining this repo will be a critical part of my full time job, I'm hoping this can ease the burden of maintenance for the rest of the community.

[esifea]

Thank you for your response.

I recall our discussion regarding upstreaming during the last meeting, and I completely agree with the decision. I must admit that I overlooked Google's project management practices, which was a concern of mine. I have noticed that many projects tend to use a specific version of MLIR.

I appreciate all your efforts in maintaining the project!

[AlexanderViand]

I'm now very much in favor of tracking LLVM upstream as closely as possible. The frequent minor adjustments are significantly easier to handle than the "everything breaks in all the ways" issues that arise when rebasing onto multiple months of "missed" MLIR development - something I learned the hard way with HECO ;)