This is an archive of the discontinued LLVM Phabricator instance.

[MLIR] Add async token/value arguments to async.execute op
ClosedPublic

Authored by ezhulenev on Sep 30 2020, 11:37 AM.

Details

Summary

Async execute operation can take async arguments as dependencies.

Change async.execute custom parser/printer format to use %value as %unwrapped: !async.value<!type> sytax.

Diff Detail

Event Timeline

ezhulenev created this revision.Sep 30 2020, 11:37 AM
Herald added a project: Restricted Project. · View Herald TranscriptSep 30 2020, 11:37 AM
ezhulenev requested review of this revision.Sep 30 2020, 11:37 AM
ezhulenev edited the summary of this revision. (Show Details)
rriddle requested changes to this revision.Sep 30 2020, 11:40 AM
rriddle added inline comments.
mlir/lib/Dialect/Async/IR/Async.cpp
232–233

Functions should not be placed in namespaces, they should be at the top-level. namespaces in .cpp files should only really be for defining local classes.

This revision now requires changes to proceed.Sep 30 2020, 11:40 AM
ezhulenev marked 2 inline comments as done.

Use namespace qualifiers to implement previously declared functions in Async.cpp

rriddle added inline comments.Sep 30 2020, 12:19 PM
mlir/lib/Dialect/Async/IR/Async.cpp
100

Is the async:: here necessary?

235

You need to check the result of this as it can fail.

239

nit: Use isa instead of dyn_cast if you don't need to use the result.

mlir/test/Dialect/Async/ops.mlir
138

Can you just infer the argument types of the region during parsing? That would remove the need to define the entry block signature.

ezhulenev updated this revision to Diff 295398.Sep 30 2020, 1:44 PM
ezhulenev marked 2 inline comments as done.

Cleanup includes + use isa for type matching

ezhulenev updated this revision to Diff 295399.Sep 30 2020, 1:46 PM
ezhulenev marked an inline comment as done.

Handle parser.resolveOperands failure in async.execute op parsing

mlir/lib/Dialect/Async/IR/Async.cpp
100

Cleaned up includes, and it's no longer ambiguous with std dialect.

mlir/test/Dialect/Async/ops.mlir
138

Yes, types could be inferred from the execute op operands, but how would I define SSA name for the unwrapped operands then? In this example %arg1: !async.value<f32> unwrapped to f32 and gets %0 ssa name in the attached region.

Harbormaster completed remote builds in B73577: Diff 295399.
herhut added inline comments.Oct 7 2020, 9:24 AM
mlir/include/mlir/Dialect/Async/IR/AsyncOps.td
68–69

Reading the code below, op.done() does not suggest a value. Maybe completionToken?

69–73

Maybe results better reflects what this is? Or resultValues?

mlir/lib/Dialect/Async/IR/Async.cpp
121–122

nit: op.getName()

122–141

Giving this a function like syntax makes it look like a function, which it is not. It does implicit capture, etc. What is the motivation for this?

126

nit: left-over tab

mlir/test/Dialect/Async/ops.mlir
138

The gpu.launch does this with extra syntax. You could have something like

async.execute(%operand as %unwrapped : async.value<foo>) -> ...

but then you would only have the as for unwrapped arguments and not others. We could also require them to be in some order. Something like

async.execute (%operand as %unwrapped : type, ...) deps (%token1, %token2)

lots of room for syntax bike-shedding. I am not a big fan of this looking too function like, as it does not have function behavior. There are no call sites for example.

mlir/test/Dialect/Async/verify.mlir
6 ↗(On Diff #295399)

// CHECK-LABEL: @no_op

13 ↗(On Diff #295399)

CHECK-LABEL: @wrong_execute_arg also below.

ezhulenev added inline comments.Oct 7 2020, 10:17 AM
mlir/lib/Dialect/Async/IR/Async.cpp
122–141

Motivation is your examples in the discourse RFC topic :) Maybe use function call syntax for it?

%token = async.execute (%arg0, %arg1): (!async.token, !async.token) -> !async.token {
}

It's a bit confusing though to see function call syntax with explicit args + implicit capture of "regular" values.

EDIT: after reading comments below I think it makes sense to separate values from tokens, how about this syntax:

%val = ... : !async.value<!type>
%tok = ... : !async.token

%token, %results  = async.execute [%token, ...](%val as %unwrapped): (!async.value<!type>) -> (!async.token, !async.value<!type>>) {
  async.yield %unwrapped : !type
}
  1. token dependencies are explicit and types of tokens are not mentioned in the signature
  2. syntax is sufficiently different (is it?) from function call

But I'm not sure how to parse %val as %unwrapped part, do you have any examples?

mehdi_amini added inline comments.Oct 7 2020, 11:00 AM
mlir/lib/Dialect/Async/IR/Async.cpp
122–141

This syntax looks much nicer to me!
If we always return a token as first result, we can also leave it out from the functional type

ezhulenev updated this revision to Diff 296863.Oct 7 2020, 10:04 PM
ezhulenev marked 9 inline comments as done.

Update async.execute op syntax

mlir/include/mlir/Dialect/Async/IR/AsyncOps.td
68–69

I changed to just token, I think that completion part is clear from the context.

mlir/lib/Dialect/Async/IR/Async.cpp
122–141

Updated printer/parser to use async.execute [%tokens] (%values as %unwrapped) syntax.

mlir/test/Dialect/Async/verify.mlir
13 ↗(On Diff #295399)

Functions that fail verification do not show up in the output.

ezhulenev updated this revision to Diff 296868.Oct 7 2020, 10:42 PM

Cleanup async.execute parsing

ezhulenev updated this revision to Diff 296871.Oct 7 2020, 11:18 PM

Use entry block arg names in async.execute op printer

herhut added inline comments.Oct 8 2020, 12:04 PM
mlir/include/mlir/Dialect/Async/IR/AsyncOps.td
55

Mega-nit: I think this indentation is off

mlir/lib/Dialect/Async/IR/Async.cpp
122–141

Beautiful!

Sorry for creating confusion with my sloppy RFC syntax.

190

You need to check the result here, as well, in case this fails.

ezhulenev updated this revision to Diff 297041.Oct 8 2020, 1:28 PM
ezhulenev marked 4 inline comments as done.

Don't forget to check ParseResult and fix indentation.

mlir/lib/Dialect/Async/IR/Async.cpp
122–141

I actually quite liked it when I saw it first time, but %value as %unwrapped is definitely a readability improvement.

ezhulenev edited the summary of this revision. (Show Details)Oct 8 2020, 1:29 PM
mehdi_amini accepted this revision.Oct 8 2020, 6:31 PM
herhut accepted this revision.Oct 9 2020, 3:31 AM
herhut added inline comments.
mlir/lib/Dialect/Async/IR/Async.cpp
197

nit: left-over tab?

ezhulenev marked an inline comment as done.Oct 9 2020, 8:49 AM
This revision is now accepted and ready to land.Oct 9 2020, 8:52 AM