Clean up namespacing.

Rebase.

Thanks Artem. I think I should be able to land it myself.

In D126158#3534750, @tra wrote:

I would suggest separating it into separate LLVM and MLIR patches.

Comment fix.

Looks good from my side but please address Uday's comments.

Here is a repro:

async with 0 async dep tokens wouldn't appear to be a meaningful configuration for the op. The lowering does check for it and fails, but should it just be disallowed?

I'm not sure. I would say the semantics are clear if an op uses async (the host does not wait for the op to complete) but no dependencies (it can run immediately without waiting for anything else), and it's OK for the current lowering to be limited in what it can handle and rely on gpu-async-region to bring it into lowering-compatible form. I kind of like the symmetry of these ops (including gpu.wait, where gpu.wait async [] needs to be valid).

The CUDA_VERSION comes from the cuda.h header file.

The gpu-async-region pass simply chains together sequences of gpu ops, with the intention of using async.execute to separate independent work that runs on separate streams. For that case, gpu ops can be synchronous during lowering from higher dialects because the async.execute regions specify which gpu ops should run in sequence and which ones can run in parallel.

Not opposed to this change at all, but what's the motivation for allowing gpu-async-region to run before gpu-kernel-outlining?

This should be sufficient:

This API was introduced in CUDA 11.2 (December 2020).
Should we #if CUDA_VERSION >= 11020 around this?

Thanks for taking care of this!

In D121279#3381610, @bondhugula wrote:

Would this fit logically in this revision or a separate revision for gpu.wait canonicalizer? This revision is meant to erase away trivial gpu.memcpy and ancillary stuff. A full-fledged gpu.wait folder/canonicalizer should ideally go into a separate commit.

I think the gpu.wait canonicalizer could be cleaning up more cases:

In D121102#3366204, @kevcadieux wrote:

Hello @csigg, there seems to be another use of the deprecated parseSourceString function in mlir/lib/CAPI/IR/IR.cpp that is causing a deprecated error in our builds. Would you mind please updating that use as well? Thanks!

Fix mlir/lib/CAPI/IR/IR.cpp as well.

Rebase.

Rebase.

Fix.

Fix.

Fix.

And again, more fixes.

More fixes.

Rebase.

Add fixes for other file moves.

Rebase.

We have settled on marking addf/mulf commutative as well (D118600) instead of removing it from minf/maxf. Abandoning this revision.

Rebase.

Update tests.

Rebase.

Simplify 1.0 matcher, add test for minf(inf, %x) -> %x.

Also fold minf(%x, +inf) -> %x, fix test.

Rebase.

Rebase.

I understand all this as "keeping commutative is fine" isn't it?

In D118398#3277316, @tra wrote:

Is it fine to leave the change in llvm/lib/Target/NVPTX/NVPTXInstrInfo.td as is?

I'd add a comment around FMINNAN that f64 variants do not actually exist. As long as we never lower to it it's not worth the trouble of refactoring tablegen to deal with a minor exception.

Add comment.

Rebase.

So it seems that you're assuming that one of the input value is returned when there is a NaN, and it would consistently be based on its position in the argument list. Is this how we define it?
Another definition could be that payload isn't guaranteed to be carried over and that we return a non-specific NaN that can be different from either of the argument.

In D118318#3274867, @mehdi_amini wrote:

Can you elaborate a bit with an example of why the commutativity isn't there with NaN?

In D118318#3274828, @rriddle wrote:

Something I'm missing here is why it would be legal to swap operands if the operation isn't commutative.

Rebase

In D118244#3273453, @mehdi_amini wrote:

I would even say that it deserve a separate revision from adding folders on simple arithmetic.

Addressing reviewer comments:

Adding float value matchers and using the same pattern for int value matchers for consistency.