[all-commits] [llvm/llvm-project] 22e413: [flang-rt] - Lightweight runtime assignment functi...

[Pranav Bhandarkar via All-commits]

  Branch: refs/heads/users/bhandarkar-pranav/issue_203915_ph2_pr1
  Home:   https://github.com/llvm/llvm-project
  Commit: 22e413e73b4466cec6c20ea8bf5533e1370fd978
      https://github.com/llvm/llvm-project/commit/22e413e73b4466cec6c20ea8bf5533e1370fd978
  Author: Pranav Bhandarkar <pranav.bhandarkar at amd.com>
  Date:   2026-08-03 (Mon, 03 Aug 2026)

  Changed paths:
    M flang-rt/lib/runtime/assign.cpp
    M flang-rt/lib/runtime/tools.cpp
    M flang-rt/unittests/Runtime/Assign.cpp
    M flang/include/flang/Runtime/assign.h

  Log Message:
  -----------
  [flang-rt] - Lightweight runtime assignment function (AssignSimple) for intrinsic-type assignments.

This PR introduces a lightweight assignment runtime path (`_FortranAAssignSimple`) for intrinsic-type arrays
with the goal of reducing compile-time overhead seen primarily in the form of severly increased time taken by LTO.
This PR includes only the changes to the runtime (flang-rt) and as such just with this PR compile-time improvements
will not be visible.

**Problem**

When compiling Fortran code with OpenMP GPU offload and `firstprivate(allocatable_array)`, LLVM's Attributor creates excessive abstract attributes analyzing complex runtime assignment machinery:

**Symptom:**
- **Test case:** 8-element allocatable integer array with `firstprivate` clause
- **Compile time:** 24.97s (vs 0.78s for `private` - **32x slower**)
- **Root cause:** LLVM Attributor analyzing complex Fortran runtime functions

**Why this happens:**

1. `firstprivate` requires copying arrays from host to device
2. Flang generates call to `_FortranAAssign(to_device, from_host)`
3. LTO pulls in 177 runtime functions from `libflang_rt.runtime.a`
4. OpenMPOpt/Attributor analyzes all 177 functions, creating **1,041,950 abstract attributes**
5. Time spent in OpenMPOpt: **9.75s (39% of total compile time)**

**The core issue:** `_FortranAAssign` handles ALL Fortran assignment cases (scalar, array, polymorphic, character, derived type, user-defined assignment, aliasing detection, finalization) with **999 basic blocks** in a single function. For a trivial integer array copy, this forces the optimizer to analyze machinery it will never execute.

>From Attributor debug output:
```
[Attributor] Update: [AAIsDead] for ... at position {fn:_FortranAAssign}
with state Live[#BB 1/999][#TBEP 1][#KDE 0]
                    ^^^
        999 basic blocks in ONE function!
```

**Overhead:**
- **Actually executed at runtime:** ~5-10 functions, ~200 basic blocks
- **Analyzed at compile-time:** 177 functions, ~1800 basic blocks
- **Overhead:** **17x-35x more code analyzed than executed**

Intrinsic types never have dynamic components requiring deferred operations, so the `WorkQueue` in `_FortranAAssign` is not really needed.
Therefore, we split the Fortran assignment runtime API based on statically known information:

**1. `_FortranAAssignSimple` (NEW) - Fast Path**
- Handles intrinsic type arrays (integer, real, complex, logical)
- Single `memmove()` for contiguous, element-wise loop for non-contiguous
- Minimal LTO pull-in (~3-4 functions vs 177)
- Runtime checks verify correct usage

**2. `_FortranAAssign` (EXISTING) - Complex Path**
- Handles derived types, polymorphic, character, user-defined assignment
- Retains full WorkQueue, finalization, aliasing detection machinery
- Only called when actually needed

`_FortranAAssignSimple` is used when ALL conditions are true:
1. Intrinsic element type (not derived type)
2. Matching ranks (no scalar-to-array broadcasting)
3. Non-volatile
4. Not polymorphic
5. Not explicit-length character
6. Not temporary LHS

This is a part of the fix for https://github.com/llvm/llvm-project/issues/203915



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