Mixed-data-model heterogeneous compilation and OpenMP offloading

Abstract

Heterogeneous computers combine a general-purpose host processor with domain-specific programmable many-core accelerators, uniting high versatility with high performance and energy efficiency. While the host manages ever-more application memory, accelerators are designed to work mainly on their local memory. This difference in addressed memory leads to a discrepancy between the optimal address width of the host and the accelerator. Today 64-bit host processors are commonplace, but few accelerators exceed 32-bit addressable local memory, a difference expected to increase with 128-bit hosts in the exascale era. Managing this discrepancy requires support for multiple data models in heterogeneous compilers. So far, compiler support for multiple data models has not been explored, which hampers the programmability of such systems and inhibits their adoption.In this work, we perform the first exploration of the feasibility and performance of implementing a mixed-data-model heterogeneous system. To support this, we present and evaluate the first mixed-data-model compiler, supporting arbitrary address widths on host and accelerator. To hide the inherent complexity and to enable high programmer productivity, we implement transparent offloading on top of OpenMP. The proposed compiler techniques are implemented in LLVM

From SW Timing Analysis and Safety Logging to HW Implementation: A Possible Solution with an Integrated and Low-Power Logger Approach

“…Certain notable architectural examples that are easily accessible for prototyping are the 32-bit RI5CY microcontroller core and the 64-bit Ariane microprocessor core [21]. Furthermore, the online community offers multi-core architectures, such as OpenPULP HERO (RI5CY), and OpenPiton (Ariane) [22,23].…”

HEROv2: Full-Stack Open-Source Research Platform for Heterogeneous Computing

“…To address mixed-data-width compilation in HEROv2, the Clang frontend has been extended to generate LLVM IR with automatically assigned address spaces. We adopt the techniques of [24], where OpenMP offloading entry points are used to infer that pointers passed to a device kernel from the host are 64-bit wide. The use of such pointers are then tracked throughout the application, such that any pointer that cannot be guaranteed to never hold a 64-bit host address is promoted to the host address space.…”

“…Unlike in HEROv2, accelerators are not programmable with a fullfeatured standard ISA, and there is thus no OpenMP offloading support and no heterogeneous API, runtime libraries, and toolchain that span across host processors and accelerators. HEROv1 [19], [54] does provide the components that enable the evaluation of heterogeneous applications on a mixed-ISA computer, but its toolchain is fundamentally limited to 32-bit hosts and accelerators [24]. Additionally, it has no API that unifies programming over multiple accelerators; it features one host and one accelerator architecture, and hardware and software are tailored to those instead of being modular; and its on-chip network is limited to simple configurations (e.g., fixed 64-bit data width) and topologies (e.g., central crossbar), which do not meet the demands of modern heterogeneous computers.…”

“…Those extensions are only available through the proprietary Intel compiler, whereas HEROv2's full toolchain is open source. Research works on GCC [69] were the first to provide an open-source heterogeneous OpenMP toolchain, but GCC's offloading compilation is fundamentally limited to the same data model (e.g., 32-bit) for host and accelerators [24]. Mixed-data-model heterogeneous compilation has been pioneered recently [24] with Clang/LLVM, and HEROv2 integrates that work into its toolchain.…”

“…Application programmers usually do not notice this: The compiler generates the correct instructions for accessing pointers outside the native (32-bit physical) address space of the accelerator. In the common case, such accesses hit in the TLB of the IOMMU and incur an overhead of only three cycles per remote memory access [24]. When an access misses in the TLB, the core either invokes the VMM library itself to add an entry to the IOMMU, or it lets a dedicated core handle the misses.…”