This adds a new function for creating pass managers that takes an
argument for the anchor string.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I'm a bit hesitant if we should rename C API in this kind of case to make sure the build breakage is visible through the symbol name change?
I could rename it to something like mlirPassManagerCreateWithAnchor but it's a bit unfortunate, mlirPassManagerCreate feels like the "right" name. Or maybe there should be both: mlirPassManagerCreate which uses the default anchor (builtin.module for now, but should probably be changed to any) and mlirPassManagerCreateWithAnchor with the anchor argument?
And I suppose the same thing about renaming applies to D136403?
I don't have a strong opinion. We don't (yet) offer any sort of API stability guarantees at this level, so just changing it is fine. There will be a compiler error, it's not like changing the type from one pointer to another. On the other hand, having mlirPassManagerCreate to work on builtin.module sounds like a reasonable default and we can have a more verbose mlirPassManagerCreateOnOperation that also needs a more verbose argument.
I concur with Alex. I have a slight preference for the mlirPassManagerCreateOnOperation approach but wouldn't insist on it.
create new function, mlirPassManagerCreateOnOperation, instead of changing the existing one