Compiler-Guided identification of critical sections in parallel code

  • Authors:
  • Stefan Kempf;Ronald Veldema;Michael Philippsen

  • Affiliations:
  • Computer Science Dept., Programming Systems Group, University of Erlangen-Nuremberg, Erlangen, Germany;Computer Science Dept., Programming Systems Group, University of Erlangen-Nuremberg, Erlangen, Germany;Computer Science Dept., Programming Systems Group, University of Erlangen-Nuremberg, Erlangen, Germany

  • Venue:
  • CC'13 Proceedings of the 22nd international conference on Compiler Construction
  • Year:
  • 2013

Quantified Score

Hi-index 0.00

Visualization

Abstract

There is a huge body of sequential legacy code that needs to be refactored for multicore processors. Especially for control code for embedded systems it is often easy to split the program into multiple threads. But it is difficult to identify critical sections to avoid data races as the legacy code hides its synchronization in a static schedule, priorities and interrupts. To ease refactoring, this paper presents a new static data-dependence analysis that identifies necessary critical sections in thread-parallel code that does not yet contain any synchronization between threads. A novel optimization pass then breaks up and shrinks the identified critical sections to maximize parallelism while preserving correctness. Our technique proved to be successful in refactoring sequential assembly-like legacy codes in an industry-sponsored project. But as refactoring projects are hard to evaluate quantitatively and as the domain specific low-level language is of limited interest, we use a standard benchmark suite for which the optimum, i.e., the minimal set of the necessary atomic block annotations is known. We removed the annotations and let the compiler attempt to rediscover them. For 5 out of 7 benchmarks, our compiler identified the same critical sections as the original programmers did by hand. For the other two benchmarks, the compiler found slightly larger (but also correct) critical sections. In all cases, the versions of the benchmarks that the compiler annotated achieved the original run-time performance.