Skip to content
  1. Mar 07, 2022
    • Jan Svoboda's avatar
      [clang][modules] NFC: Simplify and clarify test · 242b24c1
      Jan Svoboda authored
      This patch simplifies a test that checks only used module map files are reported as input files in PCM files.
      
      Instead of using opaque `diff`, this patch uses `clang -module-file-info` and `FileCheck` to verify this.
      
      Reviewed By: dexonsmith
      
      Differential Revision: https://reviews.llvm.org/D120463
      242b24c1
    • Timm Bäder's avatar
      [clang][parser] Stop dragging an EndLoc around when parsing attributes · 7b969b0b
      Timm Bäder authored
      It's almost always entirely unused and if it is used, the end of the
      attribute range can be used instead.
      
      Differential Revision: https://reviews.llvm.org/D120888
      7b969b0b
    • Qiu Chaofan's avatar
      [PowerPC] Add generic fnmsub intrinsic · b2497e54
      Qiu Chaofan authored
      Currently in Clang, we have two types of builtins for fnmsub operation:
      one for float/double vector, they'll be transformed into IR operations;
      one for float/double scalar, they'll generate corresponding intrinsics.
      
      But for the vector version of builtin, the 3 op chain may be recognized
      as expensive by some passes (like early cse). We need some way to keep
      the fnmsub form until code generation.
      
      This patch introduces ppc.fnmsub.* intrinsic to unify four fnmsub
      intrinsics.
      
      Reviewed By: shchenz
      
      Differential Revision: https://reviews.llvm.org/D116015
      b2497e54
    • William S. Moses's avatar
      [OpenMPIRBuilder] Allocate temporary at the correct block in a nested parallel · 87ec6f41
      William S. Moses authored
      The OpenMPIRBuilder has a bug. Specifically, suppose you have two nested openmp parallel regions (writing with MLIR for ease)
      
      ```
      omp.parallel {
        %a = ...
        omp.parallel {
          use(%a)
        }
      }
      ```
      
      As OpenMP only permits pointer-like inputs, the builder will wrap all of the inputs into a stack allocation, and then pass this
      allocation to the inner parallel. For example, we would want to get something like the following:
      
      ```
      omp.parallel {
        %a = ...
        %tmp = alloc
        store %tmp[] = %a
        kmpc_fork(outlined, %tmp)
      }
      ```
      
      However, in practice, this is not what currently occurs in the context of nested parallel regions. Specifically to the OpenMPIRBuilder,
      the entirety of the function (at the LLVM level) is currently inlined with blocks marking the corresponding start and end of each
      region.
      
      ```
      entry:
        ...
      
      parallel1:
        %a = ...
        ...
      
      parallel2:
        use(%a)
        ...
      
      endparallel2:
        ...
      
      endparallel1:
        ...
      ```
      
      When the allocation is inserted, it presently inserted into the parent of the entire function (e.g. entry) rather than the parent
      allocation scope to the function being outlined. If we were outlining parallel2, the corresponding alloca location would be parallel1.
      
      This causes a variety of bugs, including https://github.com/llvm/llvm-project/issues/54165 as one example.
      
      This PR allows the stack allocation to be created at the correct allocation block, and thus remedies such issues.
      
      Reviewed By: jdoerfert
      
      Differential Revision: https://reviews.llvm.org/D121061
      87ec6f41
  2. Mar 06, 2022
  3. Mar 05, 2022
  4. Mar 04, 2022
  5. Mar 03, 2022
Loading