Advancing OpenMP Offload Debugging Capabilities in LLVM

Doerfert, Johannes; Huber, Joseph; Cornelius, Melanie

doi:10.1145/3458744.3473358

Cited by 3 publications

(3 citation statements)

References 3 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…In recent work we implemented loop transformation constructions introduced in OpenMP 5.1 [70,71], asynchronous offloading for OpenMP [132], efficient lowering of idiomatic OpenMP code to GPUs (under review), OpenMP-aware compiler optimizations with informative and actionable remarks for users (under review), a portable OpenMP device (=gpu) runtime written in OpenMP 5.1 (including atomic 2) partial( 4) partial( 8) partial( 16) partial (32) partial (64) partial (128) partial( 256 support) [133], a virtual GPU as debugging friendly offloading target on the host [134], improved diagnostics and execution information [135,136]. We redone the OpenMP GPU code generation in LLVM/Clang [137] to improve performance and correctness.…”

Section: Recent Progressmentioning

confidence: 99%

See 1 more Smart Citation

ECP Software Technology Capability Assessment Report V3.0

Heroux

McInnes

et al. 2022

View full text Add to dashboard Cite

The Exascale Computing Project (ECP) Software Technology (ST) focus area is responsible for (1) developing critical software capabilities that will enable the successful execution of ECP applications and (2) providing key components of a productive and sustainable exascale computing ecosystem that will position the US Department of Energy (DOE) and the broader high-performance computing (HPC) community with a firm foundation for future extreme-scale computing capabilities.This ECP ST Capability Assessment Report (CAR) provides an overview and assessment of current ECP ST capabilities and activities, giving stakeholders and the broader HPC community information that can be used to assess ECP ST progress and plan their own efforts accordingly. ECP ST leaders commit to updating this document on regular basis (every 6-12 months). Highlights from this version of the report are presented here.This version of the CAR contains the following updates relative to the previous revision.• This report highlights the progress with the Extreme-scale Scientific Software Stack (E4S) efforts.In particular, this report discusses how E4S continues to gain traction as a first-class entity in the HPC ecosystem, enabling new conversations with users, facilities, vendors, other US agencies, and international partners.• The several-page summaries of each ECP Level 4 project were updated to reflect recent progress and next steps (Section 4). Of particular note are the experiences of our teams on early-access systems for Frontier.• The E4S is described further. E4S is now updated via quarterly releases. E4S is the primary integration and delivery vehicle for ECP ST capabilities (Section 2.1.1).• The ECP ST software development kit (SDK) effort further refined its groupings (Section 2.1.2).The ECP ST focus area represents the key bridge between exascale systems and the scientists developing applications that will run on those platforms. ECP ST efforts contribute to approximately 70 software products (Section 2.1.3) in six technical areas (Table 1). Since publishing the previous revision of the CAR, the team has continued to evolve the product dictionary of official product names, which enables more rigorous mapping of ECP ST deliverables to stakeholders (Section 2.1.4).Programming Models & Runtimes: In addition to developing key enhancements to MPI and OpenMP for scalable systems with accelerated node architectures, the team is working on performance portability layers (Kokkos and RAJA) and participating in OpenMP and OpenACC software design and development that will enable applications to write much of their source code without needing to provide vendor-specific implementations for each exascale system. One legacy of ECP ST efforts is anticipated to be a software stack that supports Intel and AMD accelerators in addition to NVIDIA's accelerators (Section 4.1).Development Tools: The team is enhancing existing widely used compilers (e.g., LLVM) and performance tools for next-generation platforms. Compilers are critical for heterogeneous archi...

show abstract

Section: Recent Progressmentioning

confidence: 99%

“…This work was complemented by a new LLVM/OpenMP GPU device runtime that helps us further close the performance gap compared to CUDA and other kernel languages [138]. Various efforts in improving development and debugging have also been integrated into LLVM/OpenMP [135,134].…”

Section: Recent Progressmentioning

confidence: 99%

ECP Software Technology Capability Assessment Report V3.0

Heroux

McInnes

et al. 2022

View full text Add to dashboard Cite

show abstract

“…A recent development is the introduction of the OpenMPIR-Builder [6] to extract out the base-language independent portion of the OpenMP lowering from the one that is specific to the Clang AST. The goal is to share the implementation of the heavy lowering between Clang and the MLIR OpenMP Dialect [2], similar to how IRBuilder is used by many language front-ends and not just Clang.…”

Section: Clang Layer Architecturementioning

confidence: 99%

Loop Transformations using Clang's Abstract Syntax Tree

Kruse¹

2021

Preprint

View full text Add to dashboard Cite

OpenMP 5.1 introduced the first loop nest transformation directives unroll and tile, and more are expected to be included in OpenMP 6.0. We discuss the two Abstract Syntax Tree (AST) representations used by Clang's implementation that is currently under development. The first representation is designed for compatibility with the existing implementation and stores the transformed loop nest in a shadow AST next to the syntactical AST. The second representation introduces a new meta AST-node OMPCanonicalLoop that guarantees that the semantic requirements of an OpenMP loop are met, and a CanonicalLoopInfo type that the OpenMPIRBuilder uses to represent literal and transformed loops. This second approach provides a better abstraction of loop semantics, removes the need for shadow AST nodes that are only relevant for code generation, allows sharing the implementation with other front-ends such as flang, but depends on the OpenMPIRBuilder which is currently under development. CCS CONCEPTS• Software and its engineering → Compilers; Parsers; Parallel programming languages; Software performance.

show abstract