Commit Graph

8 Commits

Author SHA1 Message Date
Malhar 74ddacd30d [Clang] Ensure vector predication loop metadata is always emitted when pragma is specified.
This patch ensures that vector predication and vectorization width
pragmas work together correctly/as expected. Specifically, this patch
fixes the issue that when vectorization_width > 1, the vector
predication behaviour (this would matter if it has NOT been disabled
explicitly by a pragma) was getting ignored, which was incorrect.

The fix here removes the dependence of vector predication on the
vectorization width. The loop metadata corresponding to clang loop
pragma vectorize_predicate is always emitted, if the pragma is
specified, even if vectorization is disabled by vectorize_width(1)
or vectorize(disable) since the option is also used for interleaving
by the LoopVectorize pass.

Reviewed By: dmgreen, Meinersbur

Differential Revision: https://reviews.llvm.org/D94779
2021-02-13 17:35:54 -06:00
Atmn Patel ac73b73c16 [clang] Add mustprogress and llvm.loop.mustprogress attribute deduction
Since C++11, the C++ standard has a forward progress guarantee
[intro.progress], so all such functions must have the `mustprogress`
requirement. In addition, from C11 and onwards, loops without a non-zero
constant conditional or no conditional are also required to make
progress (C11 6.8.5p6). This patch implements these attribute deductions
so they can be used by the optimization passes.

Differential Revision: https://reviews.llvm.org/D86841
2020-11-04 22:03:14 -05:00
Jordan Rupprecht 6d424a161b Revert "Recommit "[Clang] Pragma vectorize_width() implies vectorize(enable)""
This reverts commit 80371c74ae.

Given the following source:
```
void a() {
  for (;;)
    ;
}
```

It incorrectly enables vectorization (with vector width 1), as well as generating a warning that vectorization could not be performed.
2019-10-24 16:35:45 -07:00
Sjoerd Meijer 80371c74ae Recommit "[Clang] Pragma vectorize_width() implies vectorize(enable)"
This was further discussed at the llvm dev list:

http://lists.llvm.org/pipermail/llvm-dev/2019-October/135602.html

I think the brief summary of that is that this change is an improvement,
this is the behaviour that we expect and promise in ours docs, and also
as a result there are cases where we now emit diagnostics whereas before
pragmas were silently ignored. Two areas where we can improve: 1) the
diagnostic message itself, and 2) and in some cases (e.g. -Os and -Oz)
the vectoriser is (quite understandably) not triggering.

Original commit message:

Specifying the vectorization width was supposed to implicitly enable
vectorization, except that it wasn't really doing this. It was only
setting the vectorize.width metadata, but not vectorize.enable.

This should fix PR27643.

llvm-svn: 374288
2019-10-10 08:27:14 +00:00
Hans Wennborg 858a1ae37d Revert r372082 "[Clang] Pragma vectorize_width() implies vectorize(enable)"
This broke the Chromium build. Consider the following code:

  float ScaleSumSamples_C(const float* src, float* dst, float scale, int width) {
    float fsum = 0.f;
    int i;
  #if defined(__clang__)
  #pragma clang loop vectorize_width(4)
  #endif
    for (i = 0; i < width; ++i) {
      float v = *src++;
      fsum += v * v;
      *dst++ = v * scale;
    }
    return fsum;
  }

Compiling at -Oz, Clang  now warns:

  $ clang++ -target x86_64 -Oz -c /tmp/a.cc
  /tmp/a.cc:1:7: warning: loop not vectorized: the optimizer was unable to
  perform the requested transformation; the transformation might be disabled or
  specified as part of an unsupported transformation ordering
  [-Wpass-failed=transform-warning]

this suggests it's not actually enabling vectorization hard enough.

At -Os it asserts instead:

  $ build.release/bin/clang++ -target x86_64 -Os -c /tmp/a.cc
  clang-10: /work/llvm.monorepo/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:2734: void
  llvm::InnerLoopVectorizer::emitMemRuntimeChecks(llvm::Loop*, llvm::BasicBlock*): Assertion `
  !BB->getParent()->hasOptSize() && "Cannot emit memory checks when optimizing for size"' failed.

Of course neither of these are what the developer expected from the pragma.

> Specifying the vectorization width was supposed to implicitly enable
> vectorization, except that it wasn't really doing this. It was only
> setting the vectorize.width metadata, but not vectorize.enable.
>
> This should fix PR27643.
>
> Differential Revision: https://reviews.llvm.org/D66290

llvm-svn: 372225
2019-09-18 13:41:51 +00:00
Sjoerd Meijer e573a9c035 [Clang] Pragma vectorize_width() implies vectorize(enable)
Specifying the vectorization width was supposed to implicitly enable
vectorization, except that it wasn't really doing this. It was only
setting the vectorize.width metadata, but not vectorize.enable.

This should fix PR27643.

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

llvm-svn: 372082
2019-09-17 08:43:11 +00:00
Sjoerd Meijer 535efab2e5 [Clang] Pragma vectorize_predicate implies vectorize
New pragma "vectorize_predicate(enable)" now implies "vectorize(enable)",
and it is ignored when vectorization is disabled with e.g.
"vectorize(disable) vectorize_predicate(enable)".

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

llvm-svn: 368970
2019-08-15 06:24:40 +00:00
Sjoerd Meijer a48f58c97f [Clang] New loop pragma vectorize_predicate
This adds a new vectorize predication loop hint:

  #pragma clang loop vectorize_predicate(enable)

that can be used to indicate to the vectoriser that all (load/store)
instructions should be predicated (masked). This allows, for example, folding
of the remainder loop into the main loop.

This patch will be followed up with D64916 and D65197. The former is a
refactoring in the loopvectorizer and the groundwork to make tail loop folding
a more general concept, and in the latter the actual tail loop folding
transformation will be implemented.

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

llvm-svn: 366989
2019-07-25 07:33:13 +00:00