Discovered in the comments on D118748: we would like this namespace
to exist anytime Ranges exists, regardless of whether concepts syntax
is supported. Also, we'd like to fully granularize the <ranges> header,
which means not putting any loose declarations at the top level.

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

This patch adds the Sema support for `atomic compare`.

Reviewed By: ABataev

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

--warn-shared-textrel is ignored in ld.lld and obsoleted in GNU ld
(https://sourceware.org/bugzilla/show_bug.cgi?id=22909).

Note: binutils can be configured with --enable-textrel-check=[yes|error]
to make GNU ld error for text relocations by default, like ld.lld.

Reviewed By: srhines

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

Now we'll notice if a header forgets to include this magic phrase.

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

... iff the incoming values for the invokes-to-be-merged
are compatible (identical).

Separate the function clearly into:
- Checks that can be done on CI and Paired before the loop.
- The loop over all instructions between CI and Paired.
- Checks that must be done on InstsToMove after the loop.

Previously these were mostly done inside the loop in a very
confusing way.

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

Add the vslidedown and interleave patterns that I recently implemented.

Reviewed By: frasercrmck

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

This avoids a crash for scalable vectors and or scalarization for
fixed vectors.

The algorithm is different enough that I don't think it makes sense
to merge with ceil/floor/trunc. Algorithm is adapted from gcc's X86
SSE2 output.

Reviewed By: frasercrmck

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

Lack of ComputeHash inlining slows down slightly FoldingSetBase::FindNodeOrInsertPos calls.
Inlining makes it faster which matters in particular for FoldingSet users in ASTContext.

Extracted from: https://reviews.llvm.org/D118385

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

This is a generalization of the icmp fold in D118061 (and that can be abandoned).
We're looking for a disguised form of "odd * odd must be odd".
Some Alive2 proofs to show correctness:
https://alive2.llvm.org/ce/z/60Y8hz
https://alive2.llvm.org/ce/z/HfAP6R

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

This code clearly intended to forward the error, but instead
returned the non-error result.

Use proper error reporting instead of report_fatal_error().

If possible, forward the inner error instead of creating a new
one.

Even if the reference itself is dllexport, the temporary should not be.
In fact, we're already giving it internal linkage, so dllexporting it
is not just wasteful, but will fail to link, as in the example below:

  $ cat /tmp/a.cc
  void _DllMainCRTStartup() {}
  const int __declspec(dllexport) &foo = 42;

  $ clang-cl -fuse-ld=lld /tmp/a.cc /Zl /link /dll /out:a.dll
  lld-link: error: <root>: undefined symbol: int const &foo::$RT1

Differential revision: https://reviews.llvm.org/D118980

CMAKE_CXX_STANDARD 14 is set in the llvm-project/llvm folder overriding all COMPILE_OPTIONS -std=c++17.  We need to override the CXX_STANDARD property of the target in order to set the correct C++ standard flags.

Reviewed By: gchatelet

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

New device library supporting v4 and v5 has abi_version_400.bc and abi
version_500.bc.

For v5, abi_version_500.bc is linked.

For v2-4, abi_version_400.bc is linked.

For old device library, for v2-4, none of the above is linked. For v5,
error is emitted about unsupported ABI version.

Reviewed by: Artem Belevich

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

Fixes: SWDEV-321313

Only call offsetsCanBeCombined with Modify = true in cases
where it will really do something. NFC.

This is to reflect changes introduced by https://reviews.llvm.org/D118860.

[NFC][SVE] Change useSVEForFixedLengthVectorVT to allow unconditional SVE usage for NEON sized vectors.

Previously useSVEForFixedLengthVectorVT only allowed SVE usage when
the target SVE register length was known to be at least 256bit.
This was true even for NEON sized vectors, which was an artificial
restriction imposed during early SVE bring up.  This now changes so
that callers can opt to use SVE for NEON sized vectors regardless
of the SVE register length.

The patch is NFC because for all places where OverrideNEON is used
we now explicitly also check that SVE code generation for larger
than NEON vectors is enabled.  The intent is that over time these
extra checks will either be removed or the lowering disabled if the
SVE usage proves not beneficial.

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

Also add a comment explaining the difference between class
and subclass. NFCI.

We already had some patterns for UADDV(UADDLP(x)) -> UADDLV(x), this
simply expands them to the signed instructions by re-using the tablegen
patterns.

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

While nowadays SimplifyCFG knows how to hoist code from then-else blocks,
sink code from unconditional predecessors, and even promote the latter
by tail-merging `ret`/`resume` function terminators, that isn't everything.

While i (& others) have been trying to deal with merging/sinking `unreachable`,
apparently perhaps the more impactful remaining problem is merging the `throw`
calls.

If we start at the `landingpad`, all the predecessors are unwind edges of `invoke`s,
and in some cases some of the `invoke`s are mergeable.
```
/// This is a weird mix of hoisting and sinking. Visually, it goes from:
///          [...]        [...]
///            |            |
///        [invoke0]    [invoke1]
///           / \          / \
///     [cont0] [landingpad] [cont1]
/// to:
///      [...] [...]
///          \ /
///       [invoke]
///          / \
///     [cont] [landingpad]
```

This simplifies the IR/CFG, at the cost of debug info and extra PHI nodes.

Note that we don't require for *all* the `invokes` of the `landingpad`
to be mergeable, they can form more than a single set, we gracefully handle that.

For now, i completely disallowed normal destination, PHI nodes and indirect invokes
but that can be supported.

Out of all the CTMark projects, only 7zip is C++, so there isn't much impact:
https://llvm-compile-time-tracker.com/compare.php?from=ba8eb31bd9542828f6424e15a3014f80f14522c8&to=722fc871c84f14157d45c2159bc9c8c7e2825785&stat=size-total
... but there it currently causes size-total decrease.

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

This patch adds initial support for signed conditions. To do so,
ConstraintElimination maintains two separate systems, one with facts
from signed and one for unsigned conditions.

To start with this means information from signed and unsigned conditions
is kept completely separate. When it is safe to do so, information from
signed conditions may be also transferred to the unsigned system and
vice versa. That's left for follow-ups.

In the initial version, de-composition of signed values just handles
constants and otherwise just uses the value, without trying to
decompose the operation. Again this can be extended in follow-up
changes.

The main benefit of this limited signed support is proving >=s 0
pre-conditions added in D118799. But even this initial version also
fixes PR53273.

Depends on D118799.

Reviewed By: reames

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

[NFC][SimplifyCFG] 'merge compatible invokes': test with PHI nodes in unreachable normal destinations

Based on the LangRef change in D117890, this uses the elementtype
attribute rather than the pointer element type to determine the
statepoint callee function type, making statepoints compatible
with opaque pointers.

This enforces the requirement specified in D117890.

Common up all the calls to CI.setMI. NFCI.

This updates tests for the LangRef change in D117890.

At this point CI represents the combined access (original CI combined
with Paired) so it doesn't make any sense to add in Paired.width again.
NFCI.

These operations are scalarized but the result type v1i1 isn't which
needs special handling (the same as is done for the non-strict
versions of these operations).

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

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

This reverts commit b4b97ec8.

As discussed in post-commit feedback at:
https://reviews.llvm.org/D118376
...there's a stage 2 failure on a Mac running a clang-refactor tool test.

after the recent refactor, the function is unused.

OpenMP Spec 5.0 [2.12.5, Restrictions]: If a device clause in which the
ancestor device-modifier appears is present on the target construct,
then a requires directive with the reverse_offload clause must be
specified.

Reviewed By: ABataev

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