Skip to content
  1. Jan 28, 2016
    • Jonas Hahnfeld's avatar
      [OMPT] Add support for ompt_event_task_dependences and ompt_event_task_dependence_pair · 39b68624
      Jonas Hahnfeld authored
      The attached patch adds support for ompt_event_task_dependences and
      ompt_event_task_dependence_pair events from the OMPT specification [1]. These
      events only apply to OpenMP 4.0 and 4.1 (aka 4.5) because task dependencies
      were introduced in 4.0.
      
      With respect to the changes:
      
      ompt_event_task_dependences
      According to the specification, this event is raised after the task has been
      created, thefore this event needs to be raised after ompt_event_task_begin
      (in __kmp_task_start). However, the dependencies are known at
      __kmpc_omp_task_with_deps which occurs before __kmp_task_start. My modifications
      extend the ompt_task_info_t struct in order to store the dependencies of the
      task when _kmpc_omp_task_with_deps occurs and then they are emitted in
      __kmp_task_start just after raising the ompt_event_task_begin. The deps field
      is allocated and valid until the event is raised and it is freed and set
      to null afterwards.
      
      ompt_event_task_dependence_pair
      The processing of the dependences (i.e. checking whenever a dependence is
      already satisfied) is done within __kmp_process_deps. That function checks
      every dependence and calls the __kmp_track_dependence routine which gives some
      support for graphical output. I used that routine to emit the dependence pair
      but I also needed to know the sink_task. Despite the fact that the code within
      KMP_SUPPORT_GRAPH_OUTPUT refers to task_sink it may be null because
      sink->dn.task (there's a comment regarding this) and in fact it does not point
      to a proper pointer value because the value is set in node->dn.task = task;
      after the __kmp_process_deps calls in __kmp_check_deps. I have extended the
      __kmp_process_deps and __kmp_track_dependence parameter list to receive the
      sink_task.
      
      [1] https://github.com/OpenMPToolsInterface/OMPT-Technical-Report/blob/target/ompt-tr.pdf
      
      Patch by Harald Servat
      Differential Revision: http://reviews.llvm.org/D14746
      
      llvm-svn: 259038
      39b68624
  2. Nov 16, 2015
  3. Aug 26, 2015
  4. Jun 08, 2015
    • Jonathan Peyton's avatar
      Remove unused variable warnings by fooling compiler. · e8104ad0
      Jonathan Peyton authored
      Some variables are convenient to keep around even if they aren't
      really used in a release build.  This is often seen in DEBUG guarded code where the variable
      is only used in a DEBUG build.
      
      Patch by Jack Howarth
      
      llvm-svn: 239326
      e8104ad0
  5. May 07, 2015
  6. Jan 27, 2015
  7. Oct 07, 2014
    • Jim Cownie's avatar
      I apologise in advance for the size of this check-in. At Intel we do · 4cc4bb4c
      Jim Cownie authored
      understand that this is not friendly, and are working to change our
      internal code-development to make it easier to make development
      features available more frequently and in finer (more functional)
      chunks. Unfortunately we haven't got that in place yet, and unpicking
      this into multiple separate check-ins would be non-trivial, so please
      bear with me on this one. We should be better in the future.
      
      Apologies over, what do we have here?
      
      GGC 4.9 compatibility
      --------------------
      * We have implemented the new entrypoints used by code compiled by GCC
      4.9 to implement the same functionality in gcc 4.8. Therefore code
      compiled with gcc 4.9 that used to work will continue to do so.
      However, there are some other new entrypoints (associated with task
      cancellation) which are not implemented. Therefore user code compiled
      by gcc 4.9 that uses these new features will not link against the LLVM
      runtime. (It remains unclear how to handle those entrypoints, since
      the GCC interface has potentially unpleasant performance implications
      for join barriers even when cancellation is not used)
      
      --- new parallel entry points ---
      new entry points that aren't OpenMP 4.0 related
      These are implemented fully :-
            GOMP_parallel_loop_dynamic()
            GOMP_parallel_loop_guided()
            GOMP_parallel_loop_runtime()
            GOMP_parallel_loop_static()
            GOMP_parallel_sections()
            GOMP_parallel()
      
      --- cancellation entry points ---
      Currently, these only give a runtime error if OMP_CANCELLATION is true
      because our plain barriers don't check for cancellation while waiting
              GOMP_barrier_cancel()
              GOMP_cancel()
              GOMP_cancellation_point()
              GOMP_loop_end_cancel()
              GOMP_sections_end_cancel()
      
      --- taskgroup entry points ---
      These are implemented fully.
            GOMP_taskgroup_start()
            GOMP_taskgroup_end()
      
      --- target entry points ---
      These are empty (as they are in libgomp)
           GOMP_target()
           GOMP_target_data()
           GOMP_target_end_data()
           GOMP_target_update()
           GOMP_teams()
      
      Improvements in Barriers and Fork/Join
      --------------------------------------
      * Barrier and fork/join code is now in its own file (which makes it
      easier to understand and modify).
      * Wait/release code is now templated and in its own file; suspend/resume code is also templated
      * There's a new, hierarchical, barrier, which exploits the
      cache-hierarchy of the Intel(r) Xeon Phi(tm) coprocessor to improve
      fork/join and barrier performance.
      
      ***BEWARE*** the new source files have *not* been added to the legacy
      Cmake build system. If you want to use that fixes wil be required.
      
      Statistics Collection Code
      --------------------------
      * New code has been added to collect application statistics (if this
      is enabled at library compile time; by default it is not). The
      statistics code itself is generally useful, the lightweight timing
      code uses the X86 rdtsc instruction, so will require changes for other
      architectures.
      The intent of this code is not for users to tune their codes but
      rather 
      1) For timing code-paths inside the runtime
      2) For gathering general properties of OpenMP codes to focus attention
      on which OpenMP features are most used. 
      
      Nested Hot Teams
      ----------------
      * The runtime now maintains more state to reduce the overhead of
      creating and destroying inner parallel teams. This improves the
      performance of code that repeatedly uses nested parallelism with the
      same resource allocation. Set the new KMP_HOT_TEAMS_MAX_LEVEL
      envirable to a depth to enable this (and, of course, OMP_NESTED=true
      to enable nested parallelism at all).
      
      Improved Intel(r) VTune(Tm) Amplifier support
      ---------------------------------------------
      * The runtime provides additional information to Vtune via the
      itt_notify interface to allow it to display better OpenMP specific
      analyses of load-imbalance.
      
      Support for OpenMP Composite Statements
      ---------------------------------------
      * Implement new entrypoints required by some of the OpenMP 4.1
      composite statements.
      
      Improved ifdefs
      ---------------
      * More separation of concepts ("Does this platform do X?") from
      platforms ("Are we compiling for platform Y?"), which should simplify
      future porting.
      
      
      ScaleMP* contribution
      ---------------------
      Stack padding to improve the performance in their environment where
      cross-node coherency is managed at the page level.
      
      Redesign of wait and release code
      ---------------------------------
      The code is simplified and performance improved.
      
      Bug Fixes
      ---------
          *Fixes for Windows multiple processor groups.
          *Fix Fortran module build on Linux: offload attribute added.
          *Fix entry names for distribute-parallel-loop construct to be consistent with the compiler codegen.
          *Fix an inconsistent error message for KMP_PLACE_THREADS environment variable.
      
      llvm-svn: 219214
      4cc4bb4c
  8. Sep 27, 2013
Loading