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

llvm-svn: 262533

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

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

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

The monotonic/non-monotonic flags are sent to the runtime via the sched_type by
setting the 30th (non-monotonic) or 29th (monotonic) bit in the sched_type.
Macros are added to probe if monotonic or non-monotonic is specified
(SCHEDULE_HAS_[NON]MONOTONIC & SCHEDULE_HAS_NO_MODIFIERS)
and also to to get the base sched_type (SCHEDULE_WITHOUT_MODIFIERS)

Currently, nothing is done with the modifiers.

Also, this patch adds some comments on the use of the enumerations in at least
 one place where it is subtle.

Differential Revision: http://reviews.llvm.org/D17406

llvm-svn: 261906

llvm-svn: 261249

For pragma omp taskwait the runtime is called from the task context.
Therefore, the reentry frame information should be updated.

The information should be available for both taskwait event calls; therefore,
set before the first event and reset after the last event.

Patch by Joachim Protze
Differential Revision: http://reviews.llvm.org/D17145

llvm-svn: 260674

When a target task finishes and it tries to access the th_task_team from the
threads in the team where it was created, th_task_team can be NULL or point to
a different place when that thread started a nested region that is still
running. Finding the exact task_team that the threads were using is difficult
as it would require to unwind the task_state_memo_stack. So a new field was added
in the taskdata structure to point to the active task_team when the task was
created.

llvm-svn: 260615

llvm-svn: 260613

The problem is that the master's thread state was not saved before entering a
parallel region so it does not remember tasks when it returns.

llvm-svn: 260306

The -install_name linker flag will use "@rpath/" when supported in CMake
which is the recommended usage for dynamic libraries on Mac OSX.

llvm-svn: 260300

(libgomp has bool as well)

This was causing a test failure in omp_test_if.c when building with GCC in
Debug mode. I have verified that GCC versions 4.9.2 and 5.3.0 now work and
compile-tested this change with clang 3.7.1 and Intel Compiler 16.0.

Differential Revision: http://reviews.llvm.org/D16921

llvm-svn: 260204

This will be used in a later patch to find additional LLVM tools for tests and
enables reusability for libomptarget that is currently under review.

Differential Revision: http://reviews.llvm.org/D16713

llvm-svn: 259876

When building executables for Cray supercomputers, statically-linked executables
are preferred. This patch makes it possible to build the OpenMP runtime as an
archive for building statically-linked executables.  The patch adds the flag
LIBOMP_ENABLE_SHARED, which defaults to true. When true, a build of the OpenMP
runtime yields dynamic libraries. When false, a build of the OpenMP runtime
yields static libraries. There is no setting that allows both kinds of libraries
to be built.

Patch by John Mellor-Crummey

Differential Revision: http://reviews.llvm.org/D16525

llvm-svn: 259817

In: http://lists.llvm.org/pipermail/openmp-dev/2015-August/000858.html, a
performance issue was found with libomp's task dependencies.  The task
dependencies hash table has an issue with collisions. The current table size is
a power of two. This combined with the current hash function causes a large
number of collisions to occurr. Also, the current size (64) is too small for
larger applications so the table size is increased.

This patch creates a two level hash table approach for task dependencies. The
implicit task is considered the "master" or "top-level" task which has a large
static sized hash table (997), and nested tasks will have smaller hash
tables (97). Prime numbers were chosen to help reduce collisions.

Differential Revision: http://reviews.llvm.org/D16640

llvm-svn: 259113

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

When the code behind the barrier is executed, the master thread may have
already resumed execution. That's why we cannot safely assume that *pteam
is not yet freed.

This has been introduced by r258866.

llvm-svn: 259037

Current clang trunk reports _OPENMP to be 201307 = OpenMP 4.0. It doesn't
recognize '#pragma omp declare target' though (patch still pending) and
therefore fails compilation.

Differential Revision: http://reviews.llvm.org/D16631

llvm-svn: 259026

If an asynchronous inquiry peers into the runtime system
it doesn't see the freed task as the current task.

llvm-svn: 258990

Removing extraneous { } bracket sections.  Unindenting blocks of
code as a result.  Also removing empty #ifdef KMP_STUB

llvm-svn: 258986

Removing references to non-existent functions, fixing typos.

llvm-svn: 258985

llvm-svn: 258984

llvm-svn: 258910

For implcit barriers in simple parallel for loops, the order of the OMPT events
was wrong.  The barrier_{begin,end} events came after the implcit_task_end
event for the implcit barrier at the end of the parallel region. This is wrong
because the implicit task executes the barrier before ending. This patch fixes
the order of the event: It will be triggerd now just before
__kmp_pop_current_task_from_thread() is called.

Patch by Tim Cramer

Differential Revision: http://reviews.llvm.org/D16347

llvm-svn: 258866

This change fixes the bug: https://llvm.org/bugs/show_bug.cgi?id=25975
by bypassing the perl module files which try to deduce system information.
These perl modules files don't offer useful information and are from the 
original build system. They can be removed after this change.

llvm-svn: 258843

llvm-svn: 258797

llvm-svn: 258695

This change fixes one issue reported at https://llvm.org/bugs/show_bug.cgi?id=26184
There was missing cleanup code for the cached indirect lock pool. The change
will fix the reported case where it tries to initialize a lock after runtime
cleanup/reinitialization, but it is still possible that the user program runs
into another problem because most test programs have a call to __kmpc_set_lock
after cleanup/reinitialization without calling __kmpc_init_lock causing a crash/hang.

llvm-svn: 258528

Newly-built Clangs don't automatically find the SDK, and newer versions
of Mac OS X don't provide it under /usr/include etc.

llvm-svn: 258169

The release builds are configured to be reproducible, so that the
binaries compare equal between bootstrap iterations. The OpenMP
run-time build was failing like this:

runtime/src/kmp_version.c:108:79: error: expansion of date or time macro is not reproducible [-Werror,-Wdate-time]
char const __kmp_version_build_time[]     = KMP_VERSION_PREFIX "build time: " __DATE__ " " __TIME__;

Figuring as the build currently doesn't set LIBOMP_DATE, it's probably
OK to skip setting the build time here too.

llvm-svn: 257833

This new API, int kmp_set_thread_affinity_mask_initial(), is available for use
by other parallel runtime libraries inside a possibly OpenMP-registered thread.
This entry point restores the current thread's affinity mask to the affinity
mask of the application when it first began. If -1 is returned it can be assumed
that either the thread hasn't called affinity initialization or that the thread
isn't registered with the OpenMP library. If 0 is returned then, then the call
was successful. Any return value greater than zero indicates an error occurred
when setting affinity.

Differential Revision: http://reviews.llvm.org/D15867

llvm-svn: 257489

Change (__kmp_mic_type != non_mic) to (__kmp_mic_type == mic2)

llvm-svn: 257380

llvm-svn: 257378

llvm-svn: 256790

The barrier states type doesn't need to be explicitly set.

llvm-svn: 256778

llvm-svn: 256473

Recent changes to support dynamic locks didn't consider the code compiled when
OMPT_SUPPORT=true. As a result, the OMPT support was broken by recent changes
to nested locks to support dynamic locks. For OMPT to work with dynamic locks,
they need to provide a return code indicating whether a nested lock acquisition
was the first or not.

This patch moves the OMPT support for nested locks into the #else case when
DYNAMIC locks were not used. New support is needed for dynamic locks. This patch
fixes the build and leaves a placeholder where the missing OMPT callbacks can be
added either the author of the OMPT support for locks, or the dynamic
locking support.

Patch by John Mellor-Crummey

Differential Revision: http://reviews.llvm.org/D15656

llvm-svn: 256314

When users sets envirable KMP_BLOCKTIME to "infinite" (the time one busy-waits
at barrieres, etc.), the monitor thread is not useful and can be ignored. This
change prevents the creation of the monitor thread when the users sets
KMP_BLOCKTIME to "infinite".

Differential Revision: http://reviews.llvm.org/D15628

llvm-svn: 256061

llvm-svn: 256060