Skip to content
  1. Oct 18, 2016
  2. Sep 27, 2016
    • Jonathan Peyton's avatar
      Disable monitor thread creation by default. · b66d1aab
      Jonathan Peyton authored
      This change set disables creation of the monitor thread by default.  The global
      counter maintained by the monitor thread was replaced by logic that uses system
      time directly, and cyclic yielding on Linux target was also removed since there
      was no clear benefit of using it. Turning on KMP_USE_MONITOR variable (=1)
      enables creation of monitor thread again if it is really necessary for some
      reasons.
      
      Differential Revision: https://reviews.llvm.org/D24739
      
      llvm-svn: 282507
      b66d1aab
  3. Sep 09, 2016
  4. Jun 21, 2016
  5. Jun 14, 2016
  6. May 31, 2016
    • Jonathan Peyton's avatar
      Offer API for setting number of loop dispatch buffers · 067325f9
      Jonathan Peyton authored
      The problem is the lack of dispatch buffers when thousands of loops with nowait,
      about 10 iterations each, are executed by hundreds of threads. We only have
      built-in 7 dispatch buffers, but there is a need in dozens or hundreds of
      buffers.
      
      The problem can be fixed by setting KMP_MAX_DISP_BUF to bigger value. In order
      to give users same possibility I changed build-time control into run-time one,
      adding API just in case.
      
      This change adds an environment variable KMP_DISP_NUM_BUFFERS and a new API
      function kmp_set_disp_num_buffers(int num_buffers).
      
      The KMP_DISP_NUM_BUFFERS envirable works only before serial initialization,
      because during the serial initialization we already allocate buffers for the hot
      team, so it is too late to change the number of buffers later (or we need to
      reallocate buffers for all teams which sounds too complicated). The
      kmp_set_defaults() routine does not work for this envirable, because it calls
      serial initialization before reading the parameter string. So a new routine,
      kmp_set_disp_num_buffers(), is created so that it can set our internal global
      variable before the library initialization. If both the envirable and API used
      the envirable wins.
      
      Differential Revision: http://reviews.llvm.org/D20697
      
      llvm-svn: 271318
      067325f9
  7. May 27, 2016
  8. May 20, 2016
  9. May 13, 2016
    • Jonathan Peyton's avatar
      Adding new kmp_aligned_malloc() entry point · f83ae31c
      Jonathan Peyton authored
      This change adds a new entry point,
      kmp_aligned_malloc(size_t size, size_t alignment), an entry point corresponding
      to kmp_malloc() but with the capability to return aligned memory as well.
      Other allocator routines have been adjusted so that kmp_free() can be used for
      freeing memory blocks allocated by any kmp_*alloc() routine, including the new
      kmp_aligned_malloc() routine.
      
      Differential Revision: http://reviews.llvm.org/D19814
      
      llvm-svn: 269365
      f83ae31c
  10. Mar 02, 2016
    • Jonathan Peyton's avatar
      Add new OpenMP 4.5 taskloop construct feature · 283a215c
      Jonathan Peyton authored
      From the standard: The taskloop construct specifies that the iterations of one
      or more associated loops will be executed in parallel using OpenMP tasks. The
      iterations are distributed across tasks created by the construct and scheduled
      to be executed.
      
      This initial implementation uses a simple linear tasks distribution algorithm.
      Later we can add other algorithms to speedup generation of huge number of tasks
      (i.e., tree-like tasks generation should be faster).
      
      This needs to be put into the OpenMP runtime library in order for the
      compiler team to develop the compiler side of the implementation.
      
      Differential Revision: http://reviews.llvm.org/D17404
      
      llvm-svn: 262535
      283a215c
    • Jonathan Peyton's avatar
      Add new OpenMP 4.5 doacross loop nest feature · 71909c57
      Jonathan Peyton authored
      From the standard: A doacross loop nest is a loop nest that has cross-iteration
      dependence. An iteration is dependent on one or more lexicographically earlier
      iterations. The ordered clause parameter on a loop directive identifies the
      loop(s) associated with the doacross loop nest.
      
      The init/fini routines allocate/free doacross buffer(s) for each loop for each
      thread.  The wait routine waits for a flag designated by the dependence vector.
      The post routine sets the flag designated by current iteration vector.  We use
      a similar technique of shared buffer indices that covers up to 7 nowait loops
      executed simultaneously by different threads (number 7 has no real meaning,
      just heuristic value).  Also, the size of structures are kept intact via
      reducing dummy arrays.
      
      This needs to be put into the OpenMP runtime library in order for the compiler
      team to develop the compiler side of the implementation.
      
      Differential Revision: http://reviews.llvm.org/D17399
      
      llvm-svn: 262532
      71909c57
  11. Feb 25, 2016
    • Jonathan Peyton's avatar
      Add new OpenMP 4.5 affinity API · 2f7c077b
      Jonathan Peyton authored
      This change introduces the new OpenMP 4.5 affinity api surrounding
      OpenMP Places. There are six new entry points:
      
      Typically called in serial region:
       * omp_get_num_places - returns the number of places available to the execution
             environment in the place list.
       * omp_get_place_num_procs - returns the number of processors available to the
             execution environment in the specified place.
       * omp_get_place_proc_ids - returns the numerical identifiers of the processors
             available to the execution environment in the specified place.
      
      Typically called inside parallel region:
       * omp_get_place_num - returns the place number of the place to which the
             encountering thread is bound.
       * omp_get_partition_num_places - returns the number of places in the place
             partition of the innermost implicit task.
       * omp_get_partition_place_nums - returns the list of place numbers
             corresponding to the places in the place-var ICV of the innermost
             implicit task.
      
      Differential Revision: http://reviews.llvm.org/D17417
      
      llvm-svn: 261915
      2f7c077b
    • Jonathan Peyton's avatar
      Add initial support for OpenMP 4.5 task priority feature · 2851072d
      Jonathan Peyton authored
      The maximum task priority value is read from envirable: OMP_MAX_TASK_PRIORITY.
      But as of now, nothing is done with it.  We just handle the environment variable
      and add the new api: omp_get_max_task_priority() which returns that value or
      zero if it is not set.
      
      Differential Revision: http://reviews.llvm.org/D17411
      
      llvm-svn: 261908
      2851072d
  12. Jan 05, 2016
  13. Dec 11, 2015
    • Jonathan Peyton's avatar
      Hinted lock (OpenMP 4.5 feature) Updates/Fixes Part 3 · b87b5813
      Jonathan Peyton authored
      This change set includes all changes to make the code conform to the OMP 4.5 specification:
      
      * Removed hint / hinted_init definitions from include/40 files
      * Hint values are powers of 2 to enable composition (4.5 spec)
      * Hinted lock initialization functions were renamed (4.5 spec)
        kmp_init_lock_hinted -> omp_init_lock_with_hint
        kmp_init_nest_lock_hinted -> omp_init_nest_lock_with_hint
      * __kmpc_critical_section_with_hint was added to support a critical section with
        a hint (4.5 spec)
      * __kmp_map_hint_to_lock was added to convert a hint (possibly a composite) to
        an internal lock type
      * kmpc_init_lock_with_hint and kmpc_init_nest_lock_with_hint were added as
        internal entries for the hinted lock initializers. The preivous internal
        functions (__kmp_init*) were moved to kmp_csupport.c and reused in multiple
        places
      * Added the two init functions to dllexports
      * KMP_USE_DYNAMIC_LOCK is turned on if OMP_41_ENABLED is turned on
      
      Differential Revision: http://reviews.llvm.org/D15205
      
      llvm-svn: 255376
      b87b5813
  14. Aug 06, 2015
  15. Jul 09, 2015
    • Jonathan Peyton's avatar
      Enable debugger support · 8fbb49ab
      Jonathan Peyton authored
      These changes enable external debuggers to conveniently interface with 
      the LLVM OpenMP Library.  Structures are added which describe the important
      internal structures of the OpenMP Library e.g., teams, threads, etc.
      This feature is turned on by default (CMake variable LIBOMP_USE_DEBUGGER)
      and can be turned off with -DLIBOMP_USE_DEBUGGER=off.
      
      Differential Revision: http://reviews.llvm.org/D10038
      
      llvm-svn: 241832
      8fbb49ab
  16. May 07, 2015
  17. Feb 10, 2015
  18. 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
  19. Aug 05, 2014
    • Jim Cownie's avatar
      After three iterations of community review, we believe that this new · 3b81ce6b
      Jim Cownie authored
      CMAKE buld system should meet everyone's requirements.
      
      Enhanced CMake Build System Commit 
      
      * Supports Linux, Mac, Windows, and Intel® Xeon Phi builds
      * Supports building with gcc, icc, clang, and Visual Studio compilers
      * Supports bulding "fat" libraries on OS/X with clang
      * Details and documentation on how to use build system 
        are in Build_With_CMake.txt
      * To use the old CMake build system (corresponds to 
        CMakeLists.txt.old), just rename CMakeLists.txt to
        CMakeLists.txt.other and rename CMakeLists.txt.old to
        CMakeLists.txt
      
      llvm-svn: 214850
      3b81ce6b
  20. Dec 23, 2013
    • Jim Cownie's avatar
      For your Christmas hacking pleasure. · 181b4bb3
      Jim Cownie authored
      This release use aligns with Intel(r) Composer XE 2013 SP1 Product Update 2 
      
      New features
      * The library can now be built with clang (though wiht some
        limitations since clang does not support 128 bit floats)
      * Support for Vtune analysis of load imbalance
      * Code contribution from Steven Noonan to build the runtime for ARM*
        architecture processors 
      * First implementation of runtime API for OpenMP cancellation
      
      Bug Fixes
      * Fixed hang on Windows (only) when using KMP_BLOCKTIME=0
      
      llvm-svn: 197914
      181b4bb3
  21. Sep 27, 2013
Loading