This is an archive of the discontinued LLVM Phabricator instance.

[Flang][OpenMP][MLIR] Add early outlining pass for omp.target operations to flang
ClosedPublic

Authored by jsjodin on Jul 10 2023, 12:39 PM.

Details

Summary

This patch implements an early outlining transform of omp.target operations in flang. The pass is needed because optimizations may cross target op region boundaries, but with the outlining the resulting functions only contain a single omp.target op plus a func.return, so there should not be any opportunity to optimize across region boundaries.
The patch also adds an interface to be able to store and retrieve the parent function name of the original target operation. This is needed to be able to create correct kernel function names when lowering to LLVM-IR.

Diff Detail

Event Timeline

jsjodin created this revision.Jul 10 2023, 12:39 PM
Herald added a project: Restricted Project. · View Herald Transcript
jsjodin requested review of this revision.Jul 10 2023, 12:39 PM
jsjodin updated this revision to Diff 538778.Jul 10 2023, 12:46 PM

Fix a couple of comments.

domada added inline comments.Jul 11 2023, 3:12 AM
flang/test/Lower/OpenMP/omp-target-early-outlining.f90
6

Nit: Could you add some CHECK-NOT llvm-lit directives to ensure that unwanted mlir operations are not present? (For example: check if there are no instructions from the second target region)

Nit: could you make your checks more flexible? We do not need to check the exact names of constants. IMO these checks are more future proof:

!CHECK: %[[CONSTANT_VALUE:.*]] = arith.constant 10 : i32
!CHECK fir.store %[[CONSTANT_VALUE]] to %arg0 : !fir.ref<i32>

I had a quick look. Some comments and Nits inline.

The build is failing with the following error.

FrontendActions.cpp:309:29: error: no member named 'getIsDevice' in 'mlir::omp::OffloadModuleInterface'
      isDevice = offloadMod.getIsDevice();

Can you add a test that demonstrates the issue that the outlined function solves?

We probably have a test that lists the passes that are run in order. Didn't you have to update that to get tests to pass?

flang/include/flang/Optimizer/Transforms/Passes.td
303

Can you add some additional info on where this pass is called (immediate after lowering) and only required for the device flow?

flang/lib/Frontend/FrontendActions.cpp
303–313

Can this be added in a common place so that the bbc driver also gets this?

Would eraseDeadCodeAndBlocks in Bridge.cpp be a good place to add this? That function eliminates dead-code and is a pre-requisite for running other MLIR passes.

flang/lib/Optimizer/Transforms/OMPEarlyOutlining.cpp
16–17

Can these two MLIR includes be moved up?

39–41

Nit: braces not required.

flang/test/Fir/external-mangling.fir
101

Nit: newline

flang/test/Lower/OpenMP/omp-target-early-outlining.f90
2

Nit: Could you add one other target triple?

mlir/include/mlir/Dialect/OpenMP/OpenMPOpsInterfaces.td
292

Nit: Something is missing at the end of this sentence.

mlir/test/Target/LLVMIR/omptarget-region-llvm-target-device.mlir
3

Nit: Could you add a comment on what the test is testing?
Should it test the existence of func @writeindex_omp_outline_0_ in the LLVM IR? And the call to outlining and the outlined target region?

4

Nit: What is this comment for?

35–38

Nit: remove extra lines.

jsjodin updated this revision to Diff 539254.Jul 11 2023, 12:56 PM

Address review comments

jsjodin marked 9 inline comments as done.Jul 11 2023, 1:04 PM
jsjodin added inline comments.
flang/lib/Frontend/FrontendActions.cpp
303–313

Can this be added in a common place so that the bbc driver also gets this?

Would eraseDeadCodeAndBlocks in Bridge.cpp be a good place to add this? That function eliminates dead-code and is a pre-requisite for running other MLIR passes.

I'm not exactly sure how to add it in there since the entire generated function should be deleted after outlining. I was looking to see if it would be easy to add it to a function higher up in the call chain, but there seems to be some implicit state that is used to generate the function. I will take a closer look to see if it is doable. Otherwise, should this pass added to the bbc driver?

flang/test/Lower/OpenMP/omp-target-early-outlining.f90
6

Nit: Could you add some CHECK-NOT llvm-lit directives to ensure that unwanted mlir operations are not present? (For example: check if there are no instructions from the second target region)

That should not be possible since the functions are created before any optimizations. I suppose there could be a bug in the frond-end, but that is not what this test is checking.

Nit: could you make your checks more flexible? We do not need to check the exact names of constants. IMO these checks are more future proof:

Done.

!CHECK: %[[CONSTANT_VALUE:.*]] = arith.constant 10 : i32
!CHECK fir.store %[[CONSTANT_VALUE]] to %arg0 : !fir.ref<i32>
mlir/test/Target/LLVMIR/omptarget-region-llvm-target-device.mlir
3

Nit: Could you add a comment on what the test is testing?
Should it test the existence of func @writeindex_omp_outline_0_ in the LLVM IR? And the call to outlining and the outlined target region?

It should only tests that the resulting name of the generated function is correct and use the parent name that is stored in the attribute. I removed the extra checks since they are really not useful.

4

Nit: What is this comment for?

Junk, removed.

jsjodin marked 3 inline comments as done.Jul 11 2023, 1:08 PM

I had a quick look. Some comments and Nits inline.

The build is failing with the following error.

FrontendActions.cpp:309:29: error: no member named 'getIsDevice' in 'mlir::omp::OffloadModuleInterface'
      isDevice = offloadMod.getIsDevice();

Rebased and fixed.

Can you add a test that demonstrates the issue that the outlined function solves?

Yes, where do we add tests that compile from Fortran + optimizations? It requires both the front-end and optimizations.

We probably have a test that lists the passes that are run in order. Didn't you have to update that to get tests to pass?

No, I made no changes to existing tests. This is something that happens to not be triggered by the existing tests. I have an example in the abandoned patch that was supposed to fix CSE.

Can you add a test that demonstrates the issue that the outlined function solves?

Yes, where do we add tests that compile from Fortran + optimizations? It requires both the front-end and optimizations.

You can add the test in the Driver test directory.

LG. Please wait for another acceptance.

flang/lib/Frontend/FrontendActions.cpp
303–313

If it is too difficult then no need to add.
Please add a Note or a warning message saying that the location of this pass is important and other mlir transformations should not be called before this.

Also, please verify that the code/passes in eraseDeadCodeAndBlocks do not cause any unnecessary transformation that violates what you achieve by outlining.

flang/lib/Optimizer/Transforms/OMPEarlyOutlining.cpp
52

Should the visibility be set here to setVisibility(mlir::SymbolTable::Visibility::Private)?

This revision is now accepted and ready to land.Jul 11 2023, 3:17 PM
jsjodin marked an inline comment as done.Jul 12 2023, 8:29 AM
jsjodin added inline comments.
flang/lib/Frontend/FrontendActions.cpp
303–313

If it is too difficult then no need to add.
Please add a Note or a warning message saying that the location of this pass is important and other mlir transformations should not be called before this.

Also, please verify that the code/passes in eraseDeadCodeAndBlocks do not cause any unnecessary transformation that violates what you achieve by outlining.

The passes in eraseDeadCodeAndBlocks are fine. I added a warning here as well so that people are aware to not add the wrong kind of optimization.

flang/lib/Optimizer/Transforms/OMPEarlyOutlining.cpp
52

Should the visibility be set here to setVisibility(mlir::SymbolTable::Visibility::Private)?

I just checked if this was doable, but since there are no uses of these functions and setting the visibility to Private causes them to be deleted prematurely. They should be deleted once the code generation is done for the omp.target op (outlined into a kernel function) in the module translation to LLVM IR,.

jsjodin updated this revision to Diff 539577.Jul 12 2023, 8:30 AM

Rebase, fix review comments.

domada accepted this revision.Jul 13 2023, 5:30 AM

LGTM

mlir/test/Target/LLVMIR/omptarget-region-llvm-target-device.mlir
3

nit typo: stoared

Herald added a project: Restricted Project. · View Herald TranscriptJul 13 2023, 6:18 AM