[all-commits] [llvm/llvm-project] b1de32: [OMPIRBuilder] Clarify CanonicalLoopInfo. NFC.

[Michael Kruse via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: b1de32d6ddd90046171ecee0047fbf448a97e16f
      https://github.com/llvm/llvm-project/commit/b1de32d6ddd90046171ecee0047fbf448a97e16f
  Author: Michael Kruse <llvm-project at meinersbur.de>
  Date:   2021-08-12 (Thu, 12 Aug 2021)

  Changed paths:
    M clang/lib/CodeGen/CGStmtOpenMP.cpp
    M llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h
    M llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
    M llvm/unittests/Frontend/OpenMPIRBuilderTest.cpp
    M mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp

  Log Message:
  -----------
  [OMPIRBuilder] Clarify CanonicalLoopInfo. NFC.

Add in-source documentation on how CanonicalLoopInfo is intended to be used. In particular, clarify what parts of a CanonicalLoopInfo is considered part of the loop, that those parts must be side-effect free, and that InsertPoints to instructions outside those parts can be expected to be preserved after method calls implementing loop-associated directives.

CanonicalLoopInfo are now invalidated after it does not describe canonical loop anymore and asserts when trying to use it afterwards.

In addition, rename `createXYZWorkshareLoop` to `applyXYZWorkshareLoop` and remove the update location to avoid that the impression that they insert something from scratch at that location where in reality its InsertPoint is ignored. createStaticWorkshareLoop does not return a CanonicalLoopInfo anymore. First, it was not a canonical loop in the clarified sense (containing side-effects in form of calls to the OpenMP runtime). Second, it is ambiguous which of the two possible canonical loops it should actually return. It will not be needed before a feature expected to be introduced in OpenMP 6.0

Also see discussion in D105706.

Reviewed By: ftynse

Differential Revision: https://reviews.llvm.org/D107540