[all-commits] [llvm/llvm-project] ddd21a: [flang][cuda] Managed backing for -gpu=unified all...

[Vijay Kandiah via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: ddd21a5500bc65354211c0088520d0b331e862d7
      https://github.com/llvm/llvm-project/commit/ddd21a5500bc65354211c0088520d0b331e862d7
  Author: Vijay Kandiah <vkandiah at nvidia.com>
  Date:   2026-07-16 (Thu, 16 Jul 2026)

  Changed paths:
    M flang/include/flang/Lower/CUDA.h
    M flang/lib/Lower/Allocatable.cpp
    M flang/lib/Lower/ConvertVariable.cpp
    M flang/lib/Semantics/resolve-names.cpp
    A flang/test/Lower/CUDA/cuda-gpu-unified.cuf
    R flang/test/Lower/CUDA/cuda-implicit-managed-alloc.cuf

  Log Message:
  -----------
  [flang][cuda] Managed backing for -gpu=unified allocatables/pointers (#210149)

Under `-gpu=unified`, allocatables and pointers with no explicit CUDA data
attribute must be reachable from the device. Back them with CUDA managed
memory by selecting the unified allocator index at the ALLOCATE site (in
lowering), instead of stamping an implicit `Unified`/`Managed` CUDA data attribute
on the symbol in the frontend — the approach introduced in PR #209292.
This is necessary because attributing the symbol in the frontend routed every
plain allocatable/pointer through the CUDA Fortran managed descriptor
pipeline (constructor registration, `cuf.allocate`/`cuf.free`), which added
per-`ALLOCATE` overhead, forced special-casing for objects that may not legally carry a
CUDA attribute (COMMON members, derived-type components, module globals), and
changed symbol semantics used well beyond allocation. Choosing the allocator
index at the `ALLOCATE` site keeps the object a plain host allocatable/pointer while
the storage still comes from the managed allocator.



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