[all-commits] [llvm/llvm-project] a1c61a: [mlir][OpenMP] Allow composite SIMD REDUCTION and ...

[Tom Eccles via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: a1c61ac7563220f3b0180d4367937d910dc85849
      https://github.com/llvm/llvm-project/commit/a1c61ac7563220f3b0180d4367937d910dc85849
  Author: Tom Eccles <tom.eccles at arm.com>
  Date:   2025-07-15 (Tue, 15 Jul 2025)

  Changed paths:
    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
    A mlir/test/Target/LLVMIR/openmp-composite-simd-if.mlir
    M mlir/test/Target/LLVMIR/openmp-llvm.mlir
    M mlir/test/Target/LLVMIR/openmp-reduction.mlir
    M mlir/test/Target/LLVMIR/openmp-todo.mlir

  Log Message:
  -----------
  [mlir][OpenMP] Allow composite SIMD REDUCTION and IF (#147568)

Reduction support: https://github.com/llvm/llvm-project/pull/146671
If Support is fixed in this PR

The problem for the IF clause in composite constructs was that wsloop
and simd both operate on the same CanonicalLoopInfo structure: with the
SIMD processed first, followed by the wsloop. Previously the IF clause
generated code like
```
if (cond) {
  while (...) {
    simd_loop_body;
  }
} else {
  while (...) {
    nonsimd_loop_body;
  }
}
```
The problem with this is that this invalidates the CanonicalLoopInfo
structure to be processed by the wsloop later. To avoid this, in this
patch I preserve the original loop, moving the IF clause inside of the
loop:
```
while (...) {
  if (cond) {
    simd_loop_body;
  } else {
    non_simd_loop_body;
  }
}
```
On simple examples I tried LLVM was able to hoist the if condition
outside of the loop at -O3.

The disadvantage of this is that we cannot add the
llvm.loop.vectorize.enable attribute on either the SIMD or non-SIMD
loops because they both share a loop back edge. There's no way of
solving this without keeping the old design of having two different
loops: which cannot be represented using only one CanonicalLoopInfo
structure. I don't think the presence or absence of this attribute makes
much difference. In my testing it is the llvm.loop.parallel_access
metadata which makes the difference to vectorization. LLVM will
vectorize if legal whether or not this attribute is there in the TRUE
branch. In the FALSE branch this means the loop might be vectorized even
when the condition is false: but I think this is still standards
compliant: OpenMP 6.0 says that when the if clause is false that should
be treated like the SIMDLEN clause is one. The SIMDLEN clause is defined
as a "hint". For the same reason, SIMDLEN and SAFELEN clauses are
silently ignored when SIMD IF is used.

I think it is better to implement SIMD IF and ignore SIMDLEN and SAFELEN
and some vectorization encouragement metadata when combined with IF than
to ignore IF because IF could have correctness consequences whereas the
rest are optimiztion hints. For example, the user might use the IF
clause to disable SIMD programatically when it is known not safe to
vectorize the loop. In this case it is not at all safe to add the
parallel access or SAFELEN metadata.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications