This is an archive of the discontinued LLVM Phabricator instance.

[Flang][OpenMP][Lower] Refactor MLIR codegen for OpenMP constructs
ClosedPublic

Authored by skatrak on Aug 1 2023, 10:01 AM.

Details

Summary

This patch extracts MLIR codegen logic from various types of OpenMP constructs and places it into operation-specific functions. This refactoring mainly targets block constructs and unifying logic for directives that can appear on their own as well as combined with others.

The processing of clauses that do not apply to the directive being processed is avoided and code duplication for combined constructs is reduced.

Depends on D156455

Diff Detail

Event Timeline

skatrak created this revision.Aug 1 2023, 10:01 AM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptAug 1 2023, 10:01 AM
skatrak requested review of this revision.Aug 1 2023, 10:01 AM
kiranchandramohan accepted this revision.Aug 2 2023, 3:04 PM

Nice work. LG.

flang/lib/Lower/OpenMP.cpp
2171

What does the standard say for these clauses?

This revision is now accepted and ready to land.Aug 2 2023, 3:04 PM
skatrak updated this revision to Diff 547234.Aug 4 2023, 8:40 AM
skatrak marked an inline comment as done.

Use shared directive sets, restore check for unexpected/unsupported clauses, enable all parallel clause processing even as the outermost directive of a combined construct.

flang/lib/Lower/OpenMP.cpp
2171

Looking at Section 17.2 of the 5.2 Specification, this is what I see about these clauses when applied to combined constructs.

The effect of the shared, default, thread_limit, or order clause is as if it is applied to all leaf constructs that permit the clause.

The effect of the allocate clause is as if it is applied to all leaf constructs that permit the clause and to which a data-sharing attribute clause that may create a private copy of the same list item is applied.

The effect of the reduction clause is as if it is applied to all leaf constructs that permit the clause, except for the following constructs:
- The parallel construct, when combined with the sections, worksharing-loop, loop, or taskloop construct; and
- The teams construct, when combined with the loop construct.

So my understanding is that, at least at this time, all these clauses should be processed regardless of whether the parallel directive is the outermost of a combined construct. I removed the condition, but let me know if it's best to keep it in.

skatrak updated this revision to Diff 547246.Aug 4 2023, 9:23 AM

Fix format.

Since this commit we have 2 fortran tests from llvm-test-suite failing on our AArch64 bots, this is the smallest blame list:
https://lab.llvm.org/buildbot/#/builders/197/builds/8898
And this is a non-SVE bot, so it's not anything to do with scalable vectors:
https://lab.llvm.org/buildbot/#/builders/179/builds/7116

As far as I can tell, the tests build fine and run but return exit code 0 without any extra messages.

/usr/bin/test -s /home/tcwg-buildbot/worker/clang-aarch64-full-2stage/test/sandbox/build/Fortran/gfortran/regression/gomp/gfortran-regression-compile-regression__gomp__pr107214-3_f90.out

<random output from other tests>

ExitCode: 1

If you want to know how to run the test suite, look at the stages in the buildbot UI starting from recreate sandbox (https://lab.llvm.org/buildbot/#/builders/197/builds/8898/steps/11/logs/stdio). You'll need a checkout of llvm-test-suite and llvm-lnt.

I can get you any other details you need and help reproduce (though it is end of work day here, so expect a bit of a delay).

Since this commit we have 2 fortran tests from llvm-test-suite failing on our AArch64 bots, this is the smallest blame list:
https://lab.llvm.org/buildbot/#/builders/197/builds/8898
And this is a non-SVE bot, so it's not anything to do with scalable vectors:
https://lab.llvm.org/buildbot/#/builders/179/builds/7116

As far as I can tell, the tests build fine and run but return exit code 0 without any extra messages.

/usr/bin/test -s /home/tcwg-buildbot/worker/clang-aarch64-full-2stage/test/sandbox/build/Fortran/gfortran/regression/gomp/gfortran-regression-compile-regression__gomp__pr107214-3_f90.out

<random output from other tests>

ExitCode: 1

If you want to know how to run the test suite, look at the stages in the buildbot UI starting from recreate sandbox (https://lab.llvm.org/buildbot/#/builders/197/builds/8898/steps/11/logs/stdio). You'll need a checkout of llvm-test-suite and llvm-lnt.

I can get you any other details you need and help reproduce (though it is end of work day here, so expect a bit of a delay).

Thank you @DavidSpickett for looking into this and for the steps to reproduce the problem. I was able to figure out the reason for these test failures, and I reached out via the Slack channel to discuss it yesterday (https://flang-compiler.slack.com/archives/C01PY03PP9P/p1692115518910789). These tests expect compilation to fail due to using the same symbol in a map and a private or firstprivate clause. Before this patch, the test was passing because the use of private / firstprivate hit a TODO that aborted compilation. My changes made it not run into any TODOs, so compilation ended successfully and the tests started failing. The long-term solution is to add the semantics checks that these tests are exercising, which are unrelated to this patch.

@kiranchandramohan has temporarily disabled these tests for now, so I expect CI failures related to this have stopped. I'm working on a patch to reintroduce the TODOs that would trigger compilation failures in this and other currently unsupported cases and @raghavendhra is looking into adding the proper semantics checks. Hopefully this is a reasonable solution.

DavidSpickett added a comment.EditedAug 16 2023, 4:55 AM

Sounds good to me, the bots are happy now.

I don't keep up with the flang slack, but I should at least ask my flang related colleagues about these things, I'll do that in future.