This is an archive of the discontinued LLVM Phabricator instance.

[mlir] Add a new context flag for disabling/enabling multi-threading
ClosedPublic

Authored by rriddle on May 1 2020, 2:29 PM.

Details

Summary

This is useful for several reasons:

  • In some situations the user can guarantee that thread-safety isn't necessary and don't want to pay the cost of synchronization, e.g., when parsing a very large module.
  • For things like logging threading is not desirable as the output is not guaranteed to be in stable order.

This flag also subsumes the pass manager flag for multi-threading.

Diff Detail

Event Timeline

rriddle created this revision.May 1 2020, 2:29 PM
lattner accepted this revision.May 2 2020, 9:52 AM

Awesome, thank you for tackling this River, I added some suggestions above.

When this lands, I'll let you know what speedup I see on my example (and see if anything else should be guarded by this). Thank you again for working on this!

mlir/docs/PassManagement.md
804

Bikeshed: I'm not sure the precedence on this, I think that "-disable-mlir-threading" would read better and be more discoverable than "-mlir-disable-threading".

mlir/lib/IR/MLIRContext.cpp
55

When this shows up in mlir-opt etc, I think this is effectively "Disabling multi-threading in MLIR" - right? The passmgr and everything else that would create threads should be gated on the MLIRContext bit this sets.

156

Maybe it is just the way my brain works, but I'd recommend changing the internal flag (and the parameters that pass it around) to "threadingIsEnabled" to make the conditions easier to read.

You can still make it default to the same behavior of course.

This revision is now accepted and ready to land.May 2 2020, 9:52 AM
rriddle updated this revision to Diff 261658.May 2 2020, 12:29 PM
rriddle marked 4 inline comments as done.

Resolve comments

mlir/docs/PassManagement.md
804

It's consistent with the other flags we have in IR/. I started doing that a while ago to make it easier to find flags that only relate to MLIR.

This revision was automatically updated to reflect the committed changes.

Very nice River! I incorporated this into my stuff and it sped up the parser by 18%!

Random follow-on question - would it make sense to incorporate this into mlir-translate, mlir-opt etc for the "parsing the input" phases?