From 4f22c980f4cf9da0af984c4368ad0fbd42db6b83 Mon Sep 17 00:00:00 2001 From: Pekka Jaaskelainen Date: Fri, 23 May 2014 11:35:46 +0000 Subject: Updated the llvm.mem.parallel_loop_access semantics to include the possibility to have only some of the loop's memory instructions be annotated and still _help_ the loop carried dependence analysis. This was discussed in the llvmdev ML (topic: "parallel loop metadata question"). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209507 91177308-0d34-0410-b5e6-96231b3b80d8 --- docs/LangRef.rst | 32 +++++++++++++++++++++++--------- 1 file changed, 23 insertions(+), 9 deletions(-) (limited to 'docs') diff --git a/docs/LangRef.rst b/docs/LangRef.rst index ceec1bd547..fa8d3c0b75 100644 --- a/docs/LangRef.rst +++ b/docs/LangRef.rst @@ -2785,15 +2785,29 @@ for optimizations are prefixed with ``llvm.mem``. '``llvm.mem.parallel_loop_access``' Metadata ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -For a loop to be parallel, in addition to using -the ``llvm.loop`` metadata to mark the loop latch branch instruction, -also all of the memory accessing instructions in the loop body need to be -marked with the ``llvm.mem.parallel_loop_access`` metadata. If there -is at least one memory accessing instruction not marked with the metadata, -the loop must be considered a sequential loop. This causes parallel loops to be -converted to sequential loops due to optimization passes that are unaware of -the parallel semantics and that insert new memory instructions to the loop -body. +The ``llvm.mem.parallel_loop_access`` metadata refers to a loop identifier, +or metadata containing a list of loop identifiers for nested loops. +The metadata is attached to memory accessing instructions and denotes that +no loop carried memory dependence exist between it and other instructions denoted +with the same loop identifier. + +Precisely, given two instructions ``m1`` and ``m2`` that both have the +``llvm.mem.parallel_loop_access`` metadata, with ``L1`` and ``L2`` being the +set of loops associated with that metadata, respectively, then there is no loop +carried dependence between ``m1`` and ``m2`` for loops ``L1`` or +``L2``. + +As a special case, if all memory accessing instructions in a loop have +``llvm.mem.parallel_loop_access`` metadata that refers to that loop, then the +loop has no loop carried memory dependences and is considered to be a parallel +loop. + +Note that if not all memory access instructions have such metadata referring to +the loop, then the loop is considered not being trivially parallel. Additional +memory dependence analysis is required to make that determination. As a fail +safe mechanism, this causes loops that were originally parallel to be considered +sequential (if optimization passes that are unaware of the parallel semantics +insert new memory instructions into the loop body). Example of a loop that is considered parallel due to its correct use of both ``llvm.loop`` and ``llvm.mem.parallel_loop_access`` -- cgit v1.2.3