A ROSE-Based OpenMP 3.0 research compiler supporting multiple runtime libraries

  • Authors:
  • Chunhua Liao;Daniel J. Quinlan;Thomas Panas;Bronis R. de Supinski

  • Affiliations:
  • Center for Applied Scientific Computing, Lawrence Livermore National Laboratory, Livermore, CA;Center for Applied Scientific Computing, Lawrence Livermore National Laboratory, Livermore, CA;Center for Applied Scientific Computing, Lawrence Livermore National Laboratory, Livermore, CA;Center for Applied Scientific Computing, Lawrence Livermore National Laboratory, Livermore, CA

  • Venue:
  • IWOMP'10 Proceedings of the 6th international conference on Beyond Loop Level Parallelism in OpenMP: accelerators, Tasking and more
  • Year:
  • 2010

Quantified Score

Hi-index 0.00

Visualization

Abstract

OpenMP is a popular and evolving programming model for shared-memory platforms. It relies on compilers to target modern hardware architectures for optimal performance. A variety of extensible and robust research compilers are key to OpenMP’s sustainable success in the future. In this paper, we present our efforts to build an OpenMP 3.0 research compiler for C, C++, and Fortran using the ROSE source-to-source compiler framework. Our goal is to support OpenMP research for ourselves and others. We have extended ROSE’s internal representation to handle all OpenMP 3.0 constructs, thus facilitating experimenting with them. Since OpenMP research is often complicated by the tight coupling of the compiler translation and the runtime system, we present a set of rules to define a common OpenMP runtime library (XOMP) on top of multiple runtime libraries. These rules additionally define how to build a set of translations targeting XOMP. Our work demonstrates how to reuse OpenMP translations across different runtime libraries. This work simplifies OpenMP research by decoupling the problematic dependence between the compiler translations and the runtime libraries. We present an evaluation of our work by demonstrating an analysis tool for OpenMP correctness. We also show how XOMP can be defined using both GOMP and Omni. Our comparative performance results against other OpenMP compilers demonstrate that our flexible runtime support does not incur additional overhead.