[all-commits] [llvm/llvm-project] e291fa: [Flang][OpenMP][Lower] Split MLIR codegen for clau...

[Sergio Afonso via All-commits]

  Branch: refs/heads/users/skatrak/spr/clause-operands-03-genopclauses
  Home:   https://github.com/llvm/llvm-project
  Commit: e291fad68b78d28bfa73caab94ddcb978db2a602
      https://github.com/llvm/llvm-project/commit/e291fad68b78d28bfa73caab94ddcb978db2a602
  Author: Sergio Afonso <safonsof at amd.com>
  Date:   2024-03-28 (Thu, 28 Mar 2024)

  Changed paths:
    M flang/lib/Lower/OpenMP/ClauseProcessor.cpp
    M flang/lib/Lower/OpenMP/ClauseProcessor.h
    M flang/lib/Lower/OpenMP/OpenMP.cpp
    M flang/test/Lower/OpenMP/FIR/target.f90
    M flang/test/Lower/OpenMP/target.f90
    M flang/test/Lower/OpenMP/use-device-ptr-to-use-device-addr.f90

  Log Message:
  -----------
  [Flang][OpenMP][Lower] Split MLIR codegen for clauses and constructs

This patch performs several cleanups with the main purpose of normalizing the
code patterns used to trigger codegen for MLIR OpenMP operations and making the
processing of clauses and constructs independent. The following changes are
made:

- Clean up unused `directive` argument to `ClauseProcessor::processMap()`.
- Move general helper functions in OpenMP.cpp to the appropriate section of the
file.
- Create `gen<OpName>Clauses()` functions containing the clause processing code
specific for the associated OpenMP construct.
- Update `gen<OpName>Op()` functions to call the corresponding
`gen<OpName>Clauses()` function.
- Sort calls to `ClauseProcessor::process<ClauseName>()` alphabetically, to
avoid inadvertently relying on some arbitrary order. Update some tests that
broke due to the order change.
- Normalize `genOMP()` functions so they all delegate the generation of MLIR to
`gen<OpName>Op()` functions following the same pattern.
- Only process `nowait` clause on `TARGET` constructs if not compiling for the
target device.

A later patch can move the calls to `gen<OpName>Clauses()` out of
`gen<OpName>Op()` functions and passing completed clause structures instead, in
preparation to supporting composite constructs. That will make it possible to
reuse clause processing for a given leaf construct when appearing alone or in a
combined or composite construct, while controlling where the associated code is
produced.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications