Add comprehensive APIs to detect device-resident data across OpenACC
type and operation interfaces. This enables passes to identify data that
is already on the device (e.g., CUF device/managed/constant memory, GPU
address spaces) and handle it appropriately.
New interface methods:
- PointerLikeType::isDeviceData(Value): Returns true if the pointer
points to device data.
- MappableType::isDeviceData(Value): Returns true if the variable
represents device data.
- GlobalVariableOpInterface::isDeviceData(): Returns true if the global
variable is device data.
New utilities in OpenACCUtils:
- acc::isDeviceValue(Value): Checks if a value represents device data by
querying type interfaces, PartialEntityAccessOpInterface for base
entities, and AddressOfGlobalOpInterface for global symbols.
- acc::isValidValueUse(Value, Region): Checks if a value is legal in an
OpenACC region by verifying it comes from a data operation, is only used
by private clauses, or is device data.
Updated isValidSymbolUse to check
GlobalVariableOpInterface::isDeviceData()
for symbols referencing device-resident globals.
FIR implementations check for CUF data attributes (device, managed,
constant, shared, unified) on operations, block arguments, and globals.
The implementation traces through fir.rebox, fir.embox, fir.declare,
hlfir.declare, and fir.address_of to find the underlying data source.
Memref implementations check for gpu::AddressSpaceAttr on the memref
type.
Updated ACCImplicitData to use acc::isDeviceValue for generating
acc.deviceptr clauses for device-resident data instead of
copyin/copyout.
Updated OpenACCSupport::isValidValueUse to fallback to the new
acc::isValidValueUse utility.
Add a new API `isValidValueUse ` to OpenACCSupport. This is used in
ACCImplicitData to check value that are already legal in the OpenACC
region and do not require implicit clause to be generated. An example
would be a CUDA Fortran device variable that is already on the GPU.
This patch refactors the OpenACC dialect to attach recipe symbols
directly to data operations (acc.private, acc.firstprivate,
acc.reduction)
rather than to compute constructs (acc.parallel, acc.serial, acc.loop).
Motivation:
The previous design required compute constructs to carry both the recipe
symbol and the variable reference, leading to complexity. Additionally,
recipes were required even when they could be generated automatically
through MappableType interfaces.
Changes:
- Data operations (acc.private, acc.firstprivate, acc.reduction) now
require a 'recipe' attribute referencing their respective recipe
operations
- Verifier enforces recipe attribute presence for non-MappableType
operands; MappableType operands can generate recipes on demand
- Compute constructs (acc.parallel, acc.serial, acc.loop) no longer
carry recipe symbols in their operands
- Updated flang lowering to attach recipes to data operations instead
of passing them to compute constructs
Format Migration:
Old format:
```
acc.parallel private(@recipe -> %var : !fir.ref<i32>) { ... }
```
New format:
```
%private = acc.private varPtr(%var : !fir.ref<i32>)
recipe(@recipe) -> !fir.ref<i32>
acc.parallel private(%private : !fir.ref<i32>) { ... }
```
Test Updates:
- Updated all CIR and Flang OpenACC tests to new format
- Fixed CHECK lines to verify recipe attributes on data operations
The `acc.present` Op as generated by ACCImplicitData does not provide a
way to differentiate between `acc.present` ops that are generated
implicitly and the ones that are generated as result of an explicit
`default(present)` clause in the source code. This differentiation would
allow for better communication to the user on the decisions made by the
compiler while managing data automatically between the host and the
device. This commit adds this information as a discardable attribute on
the `acc.present` op.
This change adds the ACCImplicitData pass which implements the OpenACC
specification for "Variables with Implicitly Determined Data Attributes"
(OpenACC 3.4 spec, section 2.6.2).
The pass automatically generates data clause operations (copyin,
copyout, present, firstprivate, etc.) for variables used within OpenACC
compute constructs (parallel, kernels, serial) that do not already have
explicit data clauses.
Key features:
- Respects default(none) and default(present) clauses
- Handles scalar vs. aggregate variables with different semantics:
* Aggregates: present clause (if default(present)) or copy clause
* Scalars: copy clause (kernels) or firstprivate (parallel/serial)
- Generates privatization recipes when needed for firstprivate clauses
- Performs alias analysis to avoid redundant data mappings
- Ensures proper data clause ordering for partial entity access
- Generates exit operations (copyout, delete) to match entry operations
Requirements:
- Types must implement acc::MappableType and/or acc::PointerLikeType
interfaces to be considered candidates.
- Operations accessing partial entities or creating subviews should
implement acc::PartialEntityAccess and/or mlir::ViewLikeOpInterface for
proper clause ordering.
- Optionally pre-register acc::OpenACCSupport and mlir::AliasAnalysis if
custom alias analysis, variable name determination, or error reporting
is needed.
