This is an archive of the discontinued LLVM Phabricator instance.

Add an escape-hatch for conversion of funcs with blocking awaits to coroutines.
ClosedPublic

Authored by bakhtiyarneyman on Jul 23 2021, 5:55 PM.

Details

Summary

Currently TFRT does not support top-level coroutines, so this functionality will allow to have a single blocking await at the top level until TFRT implements the necessary functionality.

Diff Detail

Event Timeline

bakhtiyarneyman requested review of this revision.Jul 23 2021, 5:55 PM

I feel that what is missing from these two revisions is a more contextual description of the motivation and what we're trying to achieve and how, I don't quite have a good understanding of the design just yet.

ezhulenev added inline comments.Jul 25 2021, 8:27 AM
mlir/lib/Dialect/Async/Transforms/AsyncToAsyncRuntime.cpp
635–637

Just & is enough here, unless lambda captures by value don't see a need to specify ref captures explicitly

bakhtiyarneyman marked an inline comment as done.

Addressing comments.

bakhtiyarneyman edited the summary of this revision. (Show Details)Jul 26 2021, 4:37 PM

Currently TFRT does not support top-level coroutines, so this functionality will allow to have a single blocking await at the top level until TFRT implements the necessary functionality.

I suspect that in general this should be handled using visibility: you should only be able to rewrite the signature of private functions and not public one (which are by definition exported by the module to the outside world): would that be enough to handle the TFRT case?

We'll need to rewrite public functions at some point as well (after resolving all the issues with TFRT threading). Alternatively instead of passing list of function names it can be a boolean flag allow-rewriting-public-functions.

We'll need to rewrite public functions at some point as well (after resolving all the issues with TFRT threading). Alternatively instead of passing list of function names it can be a boolean flag allow-rewriting-public-functions.

Yeah I'd rather have the boolean flag as an interface here right now, thanks!

Addressing comments.

We'll need to rewrite public functions at some point as well (after resolving all the issues with TFRT threading). Alternatively instead of passing list of function names it can be a boolean flag allow-rewriting-public-functions.

I think this creates an unnecessary and rigid coupling between privacy and asynchronicity, so I'm not a fan of this proposal.

Not to mix visibility and asynchronicity I'd prefer to have a special attribute on functions that should not become async, this will give control to the caller who knows best (e.g. in tfrt currently entrypoint will be marked sync-only).

Use attributes as opposed to command line options.

mehdi_amini added inline comments.Jul 27 2021, 4:48 PM
mlir/include/mlir/Dialect/Async/IR/AsyncDialect.td
37

FYI: in C++14 (pre 17) you need a definition in the .cpp file as well to avoid link-time failure in some cases.

ezhulenev edited the summary of this revision. (Show Details)Jul 28 2021, 1:02 PM

Addressing comments.

Address comments.

ezhulenev updated this revision to Diff 362565.Jul 28 2021, 3:34 PM

Fix compilation

ezhulenev accepted this revision.Jul 28 2021, 3:34 PM
This revision is now accepted and ready to land.Jul 28 2021, 3:34 PM