Wed, Jul 28
Update test class name that changed.
fyi - this has some failures. I'll need to triage more. will get to it soon.
Tue, Jul 27
Mon, Jul 26
We have pre-patched npcomp (https://github.com/llvm/mlir-npcomp/pull/251) and the iree-llvm-sandbox (https://github.com/google/iree-llvm-sandbox) successfully based on this patch. Mike says that he has a pending patch for CIRCT. So I think this is ready to land. I'll plan to do so tomorrow.
Add sources custom target to ALL.
Thu, Jul 22
Makes sense. Thanks!
A couple of minor fixes found while integrating a third party project.
I've reviewed, and I think I'm understanding what's going on. I don't think I have enough CMake chops to provide serious suggestions/alternatives on the approach, so I'm just going to try it out with CIRCT and see how it goes. Assuming it works and we don't have to work around TypeID issues and whatnot, I'm satisfied!
Wed, Jul 21
if not installing into python/ anymore, can you document where things will get installed? I didn't quite parse it out of the code.
Tue, Jul 20
Fix python API on windows (some pre-existing test failures but generally works).
Fix windows visibility (verified locally).
Nice - thanks.
Thanks for the review and conversation, Mehdi. Summarizing:
Remove global property of CAPI libs.
Fix windows build better.
I'm not sure I understand the problem you're trying to fix here: having a single DSO exporting all of the C API seems valuable to me.
And I didn't quite get the problem with C unit-test linking to it? Is it because the C unit-test would embed another copy of libSupport from libMLIRPublicApi.so ?
Fix Windows build.
I don't quite get why this is the right fix, instead of pruning _DEPS to not add all the static archives instead?
Isn't the intent to dynamically link mostly to libMLIR.so ?
Fri, Jul 16
Fri, Jul 2
Thu, Jul 1
Very nice - good to see this all coming together!
Wed, Jun 30
Thanks - we should extend this doc with more detail at some point.
Jun 29 2021
Rename hasExplicitDestructor to hasNonDefaultDestructor (on a second read, this seemed like an improvement to me).
Quite nice: I didn't know if this was going to work out so easily.
Thank you. Also, i just noticed that this file was not put in a great place: can it be moved to the linalg directory?
Jun 28 2021
Update bazel build files.
Patch all dialects
Jun 27 2021
Jun 24 2021
Jun 21 2021
The problem with pulling this into an MLIRContext is that parallelism isn't specific to MLIR. It is specific to the machine that is being run on. It's not like MLIR gets some cpus and (LLVM or higher-level SW) gets others.
Have you tried shoving the global executor into a ManagedStatic?
Jun 20 2021
Ok, well I'm still not clear what is going on here - if the static dtor for the thread pool is running while there is still MLIR stuff going on then there is going to be all sorts of bad things that come unraveled. However, I'm totally ok with River's patch to add threadpool to MLIRContext.
Jun 18 2021
Jun 17 2021
I've got some pretty strong evidence that this is indeed deadlocking during verification processing, but I can't quite explain why.
This is just using llvm::parallelForEachN (not doing anything particularly fancy) so I can't imagine how it would be different than other similar things using it. It is possible this is exposing a lower level problem in LLVM threading.
In any case, let me know how I can help. I'd prefer not to revert this though, as it is a significant speedup.
Jun 16 2021
Thanks. Rename lgtm
Jun 15 2021
Thanks for cleaning this up. I'm marking approve because I could be convinced about the naming but don't love it how it is spelled in this patch. Open to other opinions.
Jun 14 2021
Some nits and notes for the future. I like that this enables scalars and is much simpler than where the capture work was headed.
This is good - thanks. I'm glad we were able to back away from the more complicated capture semantics and just directly represent scalars.
Thanks - this looks right to me.
Jun 11 2021
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.
Makes sense to me - this makes it cleaner at the call site both for C and Python. It's just a downside that you'd have a bad crash if there is a consistency b/w the count and the number of elements in the ref. The comma separated string avoids that by design and you never get an opaque crash in the C API. Note that the C API user won't typically have an ArrayRef or a higher level structure to map that to the C API. They are using C right? :-)
Jun 10 2021
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.
Jun 4 2021
Can we please have an explanation/rationale for reverts? Given the short time window, I'm left to assume something was done in error.