[clang][NFC] Generalize getSpecificAttr for const attributes (#116606)

This patch allows using `getSpecificAttr` for getting `const`
attributes. Previously, if users of this API would want to get a

[clang][NFC] Generalize getSpecificAttr for const attributes (#116606)

This patch allows using `getSpecificAttr` for getting `const`
attributes. Previously, if users of this API would want to get a const
Attribute pointer, they had to pass `getSpecificAttr<const XYZ>()`, to
get it compile. It feels like an arbitrary limitation as the constness
was already encoded in the Attribute container's value type.

show more ...

[clang] Use {} instead of std::nullopt to initialize empty ArrayRef (#109399)

Follow up to #109133.

[HLSL] add loop unroll (#93879)

spec: https://github.com/microsoft/hlsl-specs/pull/263

- `Attr.td` - Define the HLSL loop attribute hints (unroll and loop)
- `AttrDocs.td` - Add documentation fo

[HLSL] add loop unroll (#93879)

spec: https://github.com/microsoft/hlsl-specs/pull/263

- `Attr.td` - Define the HLSL loop attribute hints (unroll and loop)
- `AttrDocs.td` - Add documentation for unroll and loop
- `CGLoopInfo.cpp` - Add codegen for HLSL unroll that maps to clang
unroll expectations
- `ParseStmt.cpp` - For statements if HLSL define DeclSpecAttrs via
MaybeParseMicrosoftAttributes
- `SemaStmtAttr.cpp` - Add the HLSL loop unroll handeling

resolves #70114

dxc examples:
- for loop: https://hlsl.godbolt.org/z/8EK6Pa139
- while loop: https://hlsl.godbolt.org/z/ebr5MvEcK
- do while: https://hlsl.godbolt.org/z/be8cedoTs

Documentation:


show more ...

[Clang] Fix incorrect handling of #pragma {GCC} unroll N in dependent context (#90240)

PR https://github.com/llvm/llvm-project/pull/89567 fix the `#pragma
unroll N` crash issue in dependent context

[Clang] Fix incorrect handling of #pragma {GCC} unroll N in dependent context (#90240)

PR https://github.com/llvm/llvm-project/pull/89567 fix the `#pragma
unroll N` crash issue in dependent context, but it's introduce an new
issue:

Since https://github.com/llvm/llvm-project/pull/89567, if `N` is value
dependent, 'option' and 'state' were ` (LoopHintAttr::Unroll,
LoopHintAttr::Enable)`. Therefor, clang's code generator generated
incorrect IR metadata.

For the situation `#pragma {GCC} unroll {0|1}`, before template
instantiation, this PR tweak the 'option' to `LoopHintAttr::UnrollCount`
and 'state' to `LoopHintAttr::Numeric`. During template instantiation
and if unroll count is 0 or 1 this PR tweak 'option' to
`LoopHintAttr::Unroll` and 'state' to `LoopHintAttr::Disable`. We don't
use `LoopHintAttr::UnrollCount` here because it's will emit an redundant
LLVM IR metadata `!{!"llvm.loop.unroll.count", i32 1}` when unroll count
is 1.

---------

Signed-off-by: yronglin <yronglin777@gmail.com>

show more ...

[Clang] Allow the value of unroll count to be zero in `#pragma GCC unroll` and `#pragma unroll` (#88666)

Fixes https://github.com/llvm/llvm-project/issues/88624

GCC allows the value of loop unro

[Clang] Allow the value of unroll count to be zero in `#pragma GCC unroll` and `#pragma unroll` (#88666)

Fixes https://github.com/llvm/llvm-project/issues/88624

GCC allows the value of loop unroll count to be zero, and the values of
0 and 1 block any unrolling of the loop. This PR aims to make clang
keeps the same behavior with GCC.
https://gcc.gnu.org/onlinedocs/gcc/Loop-Specific-Pragmas.html

---------

Signed-off-by: yronglin <yronglin777@gmail.com>

show more ...

[clang] Add support for new loop attribute [[clang::code_align()]] (#70762)

This patch adds support for new loop attribute:
[[clang::code_align(N)]].
This attribute applies to a loop and specifies

[clang] Add support for new loop attribute [[clang::code_align()]] (#70762)

This patch adds support for new loop attribute:
[[clang::code_align(N)]].
This attribute applies to a loop and specifies the byte alignment for a
loop.
The attribute accepts a positive integer constant initialization
expression
indicating the number of bytes for the minimum alignment boundary.
Its value must be a power of 2, between 1 and 4096 (inclusive).

show more ...

[clang] Use std::optional instead of llvm::Optional (NFC)

This patch replaces (llvm::|)Optional< with std::optional<. I'll post
a separate patch to remove #include "llvm/ADT/Optional.h".

This is p

[clang] Use std::optional instead of llvm::Optional (NFC)

This patch replaces (llvm::|)Optional< with std::optional<. I'll post
a separate patch to remove #include "llvm/ADT/Optional.h".

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...

[clang] Add #include <optional> (NFC)

This patch adds #include <optional> to those files containing
llvm::Optional<...> or Optional<...>.

I'll post a separate patch to actually replace llvm::Option

[clang] Add #include <optional> (NFC)

This patch adds #include <optional> to those files containing
llvm::Optional<...> or Optional<...>.

I'll post a separate patch to actually replace llvm::Optional with
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...

[CodeGen] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of

[CodeGen] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...

[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 expe

[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

show more ...

[SVE] Add support to vectorize_width loop pragma for scalable vectors

This patch adds support for two new variants of the vectorize_width
pragma:

1. vectorize_width(X[, fixed|scalable]) where an op

[SVE] Add support to vectorize_width loop pragma for scalable vectors

This patch adds support for two new variants of the vectorize_width
pragma:

1. vectorize_width(X[, fixed|scalable]) where an optional second
parameter is passed to the vectorize_width pragma, which indicates if
the user wishes to use fixed width or scalable vectorization. For
example the user can now write something like:

#pragma clang loop vectorize_width(4, fixed)
or
#pragma clang loop vectorize_width(4, scalable)

In the absence of a second parameter it is assumed the user wants
fixed width vectorization, in order to maintain compatibility with
existing code.
2. vectorize_width(fixed|scalable) where the width is left unspecified,
but the user hints what type of vectorization they prefer, either
fixed width or scalable.

I have implemented this by making use of the LLVM loop hint attribute:

llvm.loop.vectorize.scalable.enable

Tests were added to

clang/test/CodeGenCXX/pragma-loop.cpp

for both the 'fixed' and 'scalable' optional parameter.

See this thread for context: http://lists.llvm.org/pipermail/cfe-dev/2020-November/067262.html

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

show more ...

[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 `mustprog

[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

show more ...

Avoid unnecessary uses of `MDNode::getTemporary`, NFC

This is a long-delayed follow-up to
5e5b85098dbeaea2cfa5d01695b5d2982634d7dd.

`TempMDNode` includes a bunch of machinery for RAUW, and should o

Avoid unnecessary uses of `MDNode::getTemporary`, NFC

This is a long-delayed follow-up to
5e5b85098dbeaea2cfa5d01695b5d2982634d7dd.

`TempMDNode` includes a bunch of machinery for RAUW, and should only be
used when necessary. RAUW wasn't being used in any of these cases... it
was just a placeholder for a self-reference.

Where the real node was using `MDNode::getDistinct`, just replace the
temporary argument with `nullptr`.

Where the real node was using `MDNode::get`, the `replaceOperandWith`
call was "promoting" the node to a distinct one implicitly due to
self-reference detection in `MDNode::handleChangedOperand`. The
`TempMDNode` was serving a purpose by delaying uniquing, but it's way
simpler to just call `MDNode::getDistinct` in the first place.

Note that using a self-reference at all in these places is a hold-over
from before `distinct` metadata existed. It was an old trick to create
distinct nodes. It would be intrusive to change, including bitcode
upgrades, etc., and it's harmless so I'm not sure there's much value in
removing it from existing schemas. After this commit it still has a tiny
memory cost (in the extra metadata operand) but no more overhead in
construction.

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

show more ...

[Clang] Add llvm.loop.unroll.disable to loops with -fno-unroll-loops.

Currently Clang does not respect -fno-unroll-loops during LTO. During
D76916 it was suggested to respect -fno-unroll-loops on a

[Clang] Add llvm.loop.unroll.disable to loops with -fno-unroll-loops.

Currently Clang does not respect -fno-unroll-loops during LTO. During
D76916 it was suggested to respect -fno-unroll-loops on a TU basis.

This patch uses the existing llvm.loop.unroll.disable metadata to
disable loop unrolling explicitly for each loop in the TU if
unrolling is disabled. This should ensure that loops from TUs compiled
with -fno-unroll-loops are skipped by the unroller during LTO.

This also means that if a loop from a TU with -fno-unroll-loops
gets inlined into a TU without this option, the loop won't be
unrolled.

Due to the fact that some transforms might drop loop metadata, there
potentially are cases in which we still unroll loops from TUs with
-fno-unroll-loops. I think we should fix those issues rather than
introducing a function attribute to disable loop unrolling during LTO.
Improving the metadata handling will benefit other use cases, like
various loop pragmas, too. And it is an improvement to clang completely
ignoring -fno-unroll-loops during LTO.

If that direction looks good, we can use a similar approach to also
respect -fno-vectorize during LTO, at least for LoopVectorize.

In the future, this might also allow us to remove the UnrollLoops option
LLVM's PassManagerBuilder.

Reviewers: Meinersbur, hfinkel, dexonsmith, tejohnson

Reviewed By: Meinersbur, tejohnson

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

show more ...

Sink more Attr.h inline methods, NFC

This has very little impact on build time, but is a mechanical pre-req
to removing the OpenMPClause.h include, which matters. Most of these
pretty print methods

Sink more Attr.h inline methods, NFC

This has very little impact on build time, but is a mechanical pre-req
to removing the OpenMPClause.h include, which matters. Most of these
pretty print methods require Expr to be complete.

show more ...

[Clang] Pragma vectorize_width() implies vectorize(enable)

Let's try this again; this has been reverted/recommited a few times. Last time
this got reverted because for this loop:

void a() {
#

[Clang] Pragma vectorize_width() implies vectorize(enable)

Let's try this again; this has been reverted/recommited a few times. Last time
this got reverted because for this loop:

void a() {
#pragma clang loop vectorize(disable)
for (;;)
;
}

vectorisation was incorrectly enabled and the vectorize.enable metadata was set
due to a logic error. But with this fixed, we now imply vectorisation when:

1) vectorisation is enabled, which means: VectorizeWidth > 1,
2) and don't want to add it when it is disabled or enabled, otherwise we would
be incorrectly setting it or duplicating the metadata, respectively.

This should fix PR27643.

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

show more ...

Revert "Recommit "[Clang] Pragma vectorize_width() implies vectorize(enable)""

This reverts commit 80371c74ae63d2f260bcc75408be9c6f81e38465.

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

Revert "Recommit "[Clang] Pragma vectorize_width() implies vectorize(enable)""

This reverts commit 80371c74ae63d2f260bcc75408be9c6f81e38465.

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.

show more ...

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

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

show more ...

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

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

show more ...

[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
se

[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

show more ...

Don't keep stale pointers to LoopInfos.

CGLoopInfo was keeping pointers to parent loop LoopInfos, but when the loop info vector grew, it reallocated the storage and invalidated all of the parent poi

Don't keep stale pointers to LoopInfos.

CGLoopInfo was keeping pointers to parent loop LoopInfos, but when the loop info vector grew, it reallocated the storage and invalidated all of the parent pointers, causing use-after-free. Manage the lifetimes of the LoopInfos separately so that the pointers aren't stale.

Patch by Bevin Hansson.

llvm-svn: 369259

show more ...

[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(d

[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

show more ...

[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 al

[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

show more ...

[CodeGen] Generate follow-up metadata for loops with more than one transformation.

Before this patch, CGLoop would dump all transformations for a loop into
a single LoopID without encoding any order

[CodeGen] Generate follow-up metadata for loops with more than one transformation.

Before this patch, CGLoop would dump all transformations for a loop into
a single LoopID without encoding any order in which to apply them.
rL348944 added the possibility to encode a transformation order using
followup-attributes.

When a loop has more than one transformation, use the follow-up
attribute define the order in which they are applied. The emitted order
is the defacto order as defined by the current LLVM pass pipeline,
which is:

LoopFullUnrollPass
LoopDistributePass
LoopVectorizePass
LoopUnrollAndJamPass
LoopUnrollPass
MachinePipeliner

This patch should therefore not change the assembly output, assuming
that all explicit transformations can be applied, and no implicit
transformations in-between. In the former case,
WarnMissedTransformationsPass should emit a warning (except for
MachinePipeliner which is not implemented yet). The latter could be
avoided by adding 'llvm.loop.disable_nonforced' attributes.

Because LoopUnrollAndJamPass processes a loop nest, generation of the
MDNode is delayed to after the inner loop metadata have been processed.
A temporary LoopID is therefore used to annotate instructions and
RAUW'ed by the actual LoopID later.

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

llvm-svn: 357415

show more ...

[OpenCL] Generate 'unroll.enable' metadata for __attribute__((opencl_unroll_hint))

Summary:
[OpenCL] Generate 'unroll.enable' metadata for __attribute__((opencl_unroll_hint))

For both !{!"llv

[OpenCL] Generate 'unroll.enable' metadata for __attribute__((opencl_unroll_hint))

Summary:
[OpenCL] Generate 'unroll.enable' metadata for __attribute__((opencl_unroll_hint))

For both !{!"llvm.loop.unroll.enable"} and !{!"llvm.loop.unroll.full"} the unroller
will try to fully unroll a loop unless the trip count is not known at compile time.
In that case for '.full' metadata no unrolling will be processed, while for '.enable'
the loop will be partially unrolled with a heuristically chosen unroll factor.

See: docs/LanguageExtensions.rst

From https://www.khronos.org/registry/OpenCL/sdk/2.0/docs/man/xhtml/attributes-loopUnroll.html

__attribute__((opencl_unroll_hint))
for (int i=0; i<2; i++)
{
...
}

In the example above, the compiler will determine how much to unroll the loop.


Before the patch for __attribute__((opencl_unroll_hint)) was generated metadata
!{!"llvm.loop.unroll.full"}, which limits ability of loop unroller to decide, how
much to unroll the loop.

Reviewers: Anastasia, yaxunl

Reviewed By: Anastasia

Subscribers: zzheng, dmgreen, jdoerfert, cfe-commits, asavonic, AlexeySotkin

Tags: #clang

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

llvm-svn: 356571

show more ...