[llvm] [LoopInfo] Don't recognize loop as parallel if it stores to out-of-loop alloca (PR #180551)

[Pekka Jääskeläinen via llvm-commits]

================
@@ -8209,34 +8209,56 @@ metadata). Currently, the only metadata making use of it is
 '``llvm.loop.parallel_accesses``' Metadata
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-The ``llvm.loop.parallel_accesses`` metadata refers to one or more
-access group metadata nodes (see ``llvm.access.group``). It denotes that
-no loop-carried memory dependence exist between it and other instructions
-in the loop with this metadata.
+The ``llvm.loop.parallel_accesses`` metadata is used to explicitly declare a
+loop as "trivially parallel", indicating that there are no memory dependencies
+between iterations. If a loop has this metadata but has memory dependencies,
+the behavior is undefined.
+
+``llvm.loop.parallel_accesses`` refers to one or more access group metadata
+nodes (see ``llvm.access.group``). In a loop with this metadata, instructions
+may have the ``llvm.access.group`` metadata to denote that no loop-carried
+memory dependence exist between those instructions, as long as the access group
+is listed in ``llvm.loop.parallel_accesses``.
 
 Let ``m1`` and ``m2`` be two instructions that both have the
-``llvm.access.group`` metadata to the access group ``g1``, respectively
-``g2`` (which might be identical). If a loop contains both access groups
-in its ``llvm.loop.parallel_accesses`` metadata, then the compiler can
+``llvm.access.group`` metadata to the access groups ``g1`` and ``g2``
+respectively (the groups can be identical). If a loop contains both access
+groups in its ``llvm.loop.parallel_accesses`` metadata, then the compiler can
 assume that there is no dependency between ``m1`` and ``m2`` carried by
 this loop. Instructions that belong to multiple access groups are
 considered having this property if at least one of the access groups
 matches the ``llvm.loop.parallel_accesses`` list.
 
-If all memory-accessing instructions in a loop and all ``alloca`` instructions
-whose address range is being written to by instructions in the loop have
-``llvm.access.group`` metadata referring to one of the access groups of a loop's
-``llvm.loop.parallel_accesses`` metadata, then the loop has no loop carried
-memory dependencies and is considered to be a parallel loop. If there is a
-loop-carried dependency, the behavior is undefined.
-
-Note that if not all memory access instructions belong to an access
-group referred to by ``llvm.loop.parallel_accesses``, then the loop must
-not be considered 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).
+A loop is declared to be trivially parallel (as in, there are no memory
+dependencies between loop iterations) if it has the
+``llvm.loop.parallel_accesses`` metadata with referring to a set of access
+groups ``G`` and fulfills the following conditions:
+
+- All memory-accessing instructions in the loop must have ``llvm.access.group``
+  metadata referring to at least one access group in ``G``.
+- If the loop has instructions that write to memory allocated via ``alloca``,
+  the corresponding ``alloca`` instruction must have the ``llvm.access.group``
+  metadata.
+
+If there is a loop-carried memory dependency in spite of the metadata, the
+behavior is undefined. If the above conditions are not fulfilled, the loop must
+not be considered as trivially parallel without further memory dependence
+analysis.
+
+These conditions exist as a fail-safe mechanism to cause loops that were
+originally parallel to be considered sequential when optimization passes that
+are unaware of the parallel semantics perform transformations or insert new
+instructions into the loop body. Note that even if the loop is no longer
+considered trivially parallel, it may still be vectorizable. It must be treated
----------------
pjaaskel wrote:

In such cases the loop must be analyzed as any sequential loop is.    (or similar, the last sentece is a little difficult)

https://github.com/llvm/llvm-project/pull/180551