llvm / llvm/llvm-project

[clang-repl][TRACKING] Bringing HIP Support to clang-repl

Open
#222,084 0 comments 1 reaction 1 assignee Claimed by @AdityaSinha149 View on GitHub
clang-repl metaissue
Dominant language
LLVM
Stars
40.5k
Forks
18.7k
PR merge metrics
PR metrics pending

Description

# Bringing HIP Support to clang-repl

This tracks the effort to enable **HIP compilation and execution in `clang-repl`**
(Clang's incremental C++ interpreter), targeting the **AMDGPU** backend. It follows
the same shape as the existing CUDA support: compile each incremental input for both
host and device, and make the device code available to the host so kernels can run.

## Overview

The work is split into four areas:

1. **Foundational compiler fixes** – small Sema/CodeGen changes that make incremental
device compilation behave correctly.
2. **HIP environment initialization** – let clang-repl set up a HIP toolchain and load
the HIP runtime.
3. **HIP device compilation** – lower incremental HIP device code and package it.
4. **Interpreter integration ("the bridge")** – connect the above so HIP kernels
typed into the REPL actually execute.

---

## Goal 1: Foundational Compiler Support

Independent compiler fixes that the rest of the work relies on. No dependencies -
these can land first, on their own.

- #218659
**Why:** In clang-repl a kernel launch (`kernel<<<>>>()`) is typed at the top level,
so there is no enclosing function. Normal compilation always has a caller, and Sema
assumed one existed - so a top-level launch tripped an assertion/error. This relaxes
that assumption so REPL-style launches are accepted.

- #217228
**Why:** HIP emits a per-compilation-unit `__hip_cuid_` global. clang-repl compiles
each input as its own module, so this global would be emitted repeatedly and collide
at JIT link time (duplicate symbol). Skipping it in incremental mode avoids those
clashes.

- #218784
**Why:** Each REPL input is a separate, unlinked device module. A `__device__` helper
defined in an earlier input is only a declaration in a later input's module, so an
internal/weak helper has nothing to link against and fails at runtime. This re-emits
the needed definition into the module that uses it. Standalone compiler change; does
not depend on the clang-repl PRs.

---

## Goal 2: HIP Environment Initialization

- #217582
Adds the `--hip` mode: sets up the HIP toolchain and loads the HIP runtime. On its
own it only initializes the environment and reports that execution isn't wired up
yet - that comes in Goal 4.
**Dependencies:** none. It only initializes the environment and doesn't compile or
run any device code yet, so it passes on its own.

---

## Goal 3: HIP Device Compilation

- #218337
Adds the piece that compiles incremental HIP *device* code and packages it for the
host, mirroring the existing CUDA device path.
**Dependencies:** none. This PR only adds the device-parser code; it isn't connected
to the `--hip` execution flow and has no tests of its own, so it can be reviewed and
merged independently.

---

## Goal 4: Interpreter Integration - "The Bridge"

- #218848
Wires the HIP device compiler into the interpreter so kernels typed at the REPL are
compiled for the device and run - this is the piece that makes HIP actually work
end-to-end in clang-repl.

**Needs these two PRs:**
- **#217582 (HIP environment)** - provides the host/device HIP setup the connector
plugs into. Without it there's no `--hip` environment for the bridge to extend, so
it can't compile or run.
- **#218337 (`IncrementalHIPDeviceParser`)** - provides the device compilation the
connector drives. Without it there's no HIP device code being produced, so kernels
can't actually execute.

**Also needed for the end-to-end tests to pass:** the Goal 1 fixes - #218659
(top-level kernel launches are accepted), #217228 (no `__hip_cuid_` duplicate-symbol
clashes during real per-module device codegen), and #218784 (cross-input `__device__`
helpers link at runtime).

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.