This is an archive of the discontinued LLVM Phabricator instance.

[MLIR] Ensure `gpu.func` must be inside a `gpu.module`.
ClosedPublic

Authored by frgossen on Apr 21 2020, 12:09 AM.

Details

Summary

Verify that gpu.func can only live inside a gpu.module.
Update tests accordingly.

Diff Detail

Event Timeline

frgossen created this revision.Apr 21 2020, 12:09 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 21 2020, 12:09 AM
rriddle added inline comments.Apr 21 2020, 12:53 AM
mlir/test/Dialect/GPU/promotion.mlir
55

You can remove all of the empty module wrappers, module is implicitly the top-level operation.

mlir/test/lib/Transforms/TestGpuMemoryPromotion.cpp
28

Can you just change the pipeline specification in the tests instead of changing this pass?

30

MLIR uses camelCase for variable names.

herhut requested changes to this revision.Apr 21 2020, 1:11 AM

Nice!

mlir/test/Dialect/GPU/promotion.mlir
1

Maybe something like

// RUN: mlir-opt -allow-unregistered-dialect -pass-pipeline='module(gpu.module(gpu.func(test-gpu-memory-promotion)))' -split-input-file %s | FileCheck %s

is enough to direct the test pass to the functions through the extra wrapping modules.

11

Why this change?

mlir/test/lib/Transforms/TestGpuMemoryPromotion.cpp
28

See my above comment for how to do this. You can then revert these changes,

This revision now requires changes to proceed.Apr 21 2020, 1:11 AM
frgossen updated this revision to Diff 258944.Apr 21 2020, 3:06 AM
frgossen marked 9 inline comments as done.

Simplify test case.

frgossen added inline comments.Apr 21 2020, 3:10 AM
mlir/test/Dialect/GPU/promotion.mlir
11

Was not intended. Locally, I did not see this because all the indented lines appear as a change.

55

Didn't know that. Thanks!

mlir/test/lib/Transforms/TestGpuMemoryPromotion.cpp
28

That's much nicer. Thanks!

ftynse accepted this revision.Apr 21 2020, 3:53 AM
herhut accepted this revision.Apr 21 2020, 4:43 AM

Thanks!

This revision is now accepted and ready to land.Apr 21 2020, 4:43 AM
mravishankar requested changes to this revision.Apr 21 2020, 8:54 AM
mravishankar added a subscriber: mravishankar.

@ftynse , @herhut is this giving any added semantic advantage? I have been trying to see if there is a way to target gpu.func directly without going through gpu.launch + outlining. Having the requirement that a gpu.func always live in a gpu.module seems too restrictive. Just want to understand the advantage apart from the fact that all gpu.func need to live in a module "separate" from the host side.

This revision now requires changes to proceed.Apr 21 2020, 8:54 AM

@ftynse , @herhut is this giving any added semantic advantage? I have been trying to see if there is a way to target gpu.func directly without going through gpu.launch + outlining. Having the requirement that a gpu.func always live in a gpu.module seems too restrictive. Just want to understand the advantage apart from the fact that all gpu.func need to live in a module "separate" from the host side.

We always had a requirement that gpu.funcs live in a somehow special module. Originally, it was a module with a kernel_module attribute. This is necessary to pick out the modules that should be translated to device-specific dialects. Later, gpu.module was introduced, but the old condition with the attribute was not removed. This change basically completes the transition.

I do see some value in having a dedicated gpu.module to clearly separate what is intended for device and what is not. Your issue with generating a gpu.func without gpu.launch_func seems mostly orthogonal: this is a matter of writing the conversion, not of the rules the resulting IR must follow. If you have another conversion pass (or just IR building code) that creates a gpu.func, it can equally create a gpu.module first. Not having a gpu.module would put the semantics in a weird state when, for example, the same function is called from both gpu.func and from std.func or if there is some global state mutation.

mravishankar accepted this revision.Apr 23 2020, 7:16 AM

Sorry for the delay. Let's land this as is. If I have a more concrete issue/suggestion on this aspect, I can revisit this.

This revision is now accepted and ready to land.Apr 23 2020, 7:16 AM
This revision was automatically updated to reflect the committed changes.