@sumesh13 Could you also please mention whether some of the methods were just moved without any change? That's useful in the commit summary.

Can you fix the foor -> for typo in the revision title? Also "scf for" in the title will be useful.

LGTM - nice improvement and covers a useful case.

Thanks for fixing this. Some minor comments.

Minor update to test cases.

Rebase on upstream tip. Bring code to date.

Update commit summary - fix revision number.

Update revision summary

Drop duplicate attr dict parsing. Fix stale comment.

Unintended duplicate

Rebase on upstream tip. Move op to SCF dialect.

@pifon2a Could I request adding a commit summary (even if one line) on what caused the change? (for eg., "Op dropped because of ...".) Changes like these shouldn't leave the commit summary empty I think - You could even just paste a link to a discourse thread if it was discussed there.

Interesting!

The commit summary is outdated/does not match the fix. Furthermore, a deque is not needed here any more.

Thank you for the reviews!

Address reviewer comments. Rebase on tip.

I just had superficial comments. Please do go with @jpienaar or one of the other reviewers' comments.

@wsmoses MemRefDataFlow has just been moved and been renamed. Could you rebase right away? (so that the rebase becomes easy with no further intervening commits)

Thanks for fixing this - sorry I had missed updating flang.

Update commit title/summary on phab.

Mark the change NFC.

Make the test case simpler/direct.

Fix comments.

Fix stale comments.

1. Please add a test case.

This is now moot given std.execute_region suits the scf dialect and the yield op there could terminate it.

Drop unnecessary include STLExtras.h

Looks good - thanks!

Switched to list of strings on Python API and <count, MlirStringRef array> on the CAPI.

Switch to list of strings on Python API.

In D104009#2812418, @mehdi_amini wrote:

I would have wrote: ..., int numPaths, const MlirStringRef *libPaths).

This is the kind of API that I expect the user to map to an ArrayRef on the other side: the C API is unsafe (by nature somehow...) but the chance for error should be almost none because this is only a "binding" API and safe constructs can be used to wrap around this.

In D104009#2810798, @mehdi_amini wrote:

+1 to Stella's comment :)

(Btw, what did you mean by "string views" for a C API?)

https://github.com/llvm/llvm-project/blob/main/mlir/include/mlir-c/Support.h#L52-L67

In D104009#2809774, @stellaraccident wrote:

All else being equal, it is better to not be in the business of textually manipulating file paths with ad hoc separators. While a bit more typing, would you be open to changing the c API to take a size and pointer to an array of string views? Then on the python side, accept a list of strings.

I know it's annoying but I've been bitten by this kind of path munging on multiple occasions.

Drop unnecessary import.

Thanks for addressing everything - LGTM!

I'll be able to review this tomorrow, but a few really minor things I noticed.

Thanks for extending this pass. Comments below.