In preparation for D92078

The synopsis now reflects what's implemented. It does NOT reflect
all of what's specified in C++20. The "constexpr in C++20" markings
are still missing from these 12 algorithms, because they are still
unimplemented by libc++:

    reverse partition sort nth_element next_permutation prev_permutation
    push_heap pop_heap make_heap sort_heap partial_sort partial_sort_copy

All of the above algorithms were excluded from [P0202].

All of the above algorithms were made constexpr in [P0879] (along with
swap_ranges, iter_swap, and rotate — we've already implemented those three).

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

These had been waiting on the ability to use `std::copy` from
constexpr code (which in turn had been waiting on the ability to
use `is_constant_evaluated()` to switch between `memmove` and non-`memmove`
implementations of `std::copy`). That work landed a while ago,
so these algorithms can all be constexpr in C++20 now.

Simultaneously, update the tests for the set algorithms.

- Use an element type with "equivalent but not identical" values.
- The custom-comparator tests now pass something different from `operator<`.
- Make the constexpr coverage match the non-constexpr coverage.

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

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

Add vfsqrt, vfcmp, vfmax, and vfmin intrinsic instructions and
regression tests.

Reviewed By: simoll

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

Migrate `ASTImporter::Import` over to using the `FileEntryRef` overload
of `SourceManager::createFileID`. No functionality change here.

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

Initialize the fields inline instead of having to manually write out a
default constructor.

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

`ParseDirective` in VerifyDiagnosticConsumer.cpp is already calling
`translateFile`, so use the `FileID` returned by that to call
`translateLineCol` instead of using the more heavyweight
`translateFileLineCol`.

No functionality change here.

Previously these directives were always interpreted as having an extra
blank line after them.

Reviewed By: MaskRay

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

Prep commit already migrated users over to std::aligned_union_t; this
just deletes the type / header / test.

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

More carefully worded description. Added constructor to options.

Reviewed By: nicolasvasilache

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

This header was introduced in c7cae0e4.

They are currently implicit because TargetMachine::shouldAssumeDSOLocal implies
dso_local.

For external data, clang -fno-pic emits the dso_local specifier for ELF and
non-MinGW COFF. Adding explicit dso_local makes these tests in align with the
clang behavior and helps implementing an option to use GOT indirection for
external data access in -fno-pic mode (to avoid copy relocations).

This is a child diff of D92261.

This diff adds APIs that return shadow type/value/zero from origin
objects. For the time being these APIs simply returns primitive
shadow type/value/zero. The following diff will be implementing the
conversion.

As D92261 explains, some cases still use primitive shadow during
the incremential changes. The cases include
1) alloca/load/store
2) custom function IO
3) vectors
At the cases this diff does not use the new APIs, but uses primitive
shadow objects explicitly.

Reviewed-by: morehouse

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

The variables used in atomic construct should be captured in outer
task-based regions implicitly. Otherwise, the compiler will crash trying
to find the address of the local variable.

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

previously, invocations of std::sort(T**, T**) casted the arguments to
(size_t *). this breaks sorting on systems for which pointers don't fit
in a size_t. change the cast to (uintptr_t *) and add a test.

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

This function doesn't seem to be used in-tree outside tests.
However clangd wants to use it soon, and having the CDB be self-contained seems
reasonable.

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

Prepare to delete `AlignedCharArrayUnion` by migrating its users over to
`std::aligned_union_t`.

I will delete `AlignedCharArrayUnion` and its tests in a follow-up
commit so that it's easier to revert in isolation in case some
downstream wants to keep using it.

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

This covers a branch in storeShadow.

Reviewed-by: morehouse

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

Add clause validity tests for the data construct. The default clause can appear only once
and this was not enforce in the ACC.td.

Reviewed By: sameeranjoshi

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

The current state of the clang-formatted-ness of the LLVM project hasn't been updated since June bring it upto date

This reverts commit e4606543.

Previous patch (9a465057) did not fix the problem.
https://bugs.llvm.org/show_bug.cgi?id=48228

If the <new> is included too early, before CUDA-specific defines are available,
just include-next the standard <new> and undo the include guard.  CUDA-specific
variants of operator new/delete will be declared if/when <new> is used from the
CUDA source itself, when all CUDA-related macros are available.

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

All the users of `AlignedCharArrayUnion` were changed in
5b267fb7 to stop peeking inside (to look
at `buffer`), so this finishes gutting it. It's now an alias of
`std::aligned_union_t`, with a minor difference in template parameters
(`std::aligned_union_t` takes a minimum size and 0+ types, whereas this
just takes 1+ types... maybe a bit simpler to use correctly?).

A follow up will remove `AlignedCharArrayUnion` entirely, inlining this
alias into its users.

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

The companion RFC (http://lists.llvm.org/pipermail/llvm-dev/2020-October/145850.html

) gives lots of details on the overall strategy, but we summarize it here:

LLVM IR involving vector types is going to be selected using pseudo instructions (only MachineInstr). These pseudo instructions contain dummy operands to represent the vector type being operated and the vector length for the operation.
These two dummy operands, as set by instruction selection, will be used by the custom inserter to prepend every operation with an appropriate vsetvli instruction that ensures the vector architecture is properly configured for the operation. Not in this patch: later passes will remove the redundant vsetvli instructions.
Register classes of tuples of vector registers are used to represent vector register groups (LMUL > 1).
Those pseudos are eventually lowered into the actual instructions when emitting the MCInsts.
About the patch:

Because there is a bit of initial infrastructure required, this is the minimal patch that allows us to select instructions for 3 LLVM IR instructions: load, add and store vectors of integers. LLVM IR operations have "whole-vector" semantics (as in they generate values for all the elements).

Later patches will extend the information represented in TableGen.

Authored-by: Roger Ferrer Ibanez <rofirrim@gmail.com>
Co-Authored-by: Evandro Menezes <evandro.menezes@sifive.com>
Co-Authored-by: Craig Topper <craig.topper@sifive.com>

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

Add couple of clause validity tests for the update directive and check for
the restriction where at least self, host or device clause must appear on the directive.

Reviewed By: sameeranjoshi

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

Update all the users of `AlignedCharArrayUnion` to stop peeking inside
(to look at `buffer`) so that a follow-up patch can replace it with an
alias to `std::aligned_union_t`.

This was reviewed as part of https://reviews.llvm.org/D92512, but I'm
splitting this bit out to commit first to reduce churn in case the
change to `AlignedCharArrayUnion` needs to be reverted for some
unexpected reason.

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

It was added in commit 6be11e35, "[libcxx] Implement c++2a char8_t input/output of std::filesystem::path".

It was added in commit 0b71bf79, "[libcxx] [test] Add a test for conversions between wchar_t, utf8, char16_t, char32_t and windows native narrow code pages"

Original commit rG112b3cb6 introduced non-determinism in subtarget
generator due to iteration over DenseMap. New patch fixes this changing
ProcModelMapTy from DenseMap to std::map.

Instead of trying to pattern match the code produced by ISD::ABS expansion, just custom legalize ISD::ABS to the desired sequence.

The one test change is because a DAG combine for (neg (abs)) is no longer firing because ISD::ABS is now Custom instead of Expand.

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

This makes the llvm-objdump output much more readable and closer to binutils objdump. This builds on D76591

It requires changing the OperandType for certain immediates to "OPERAND_PCREL" so tablegen will generate code to pass the instruction's address. This means we can't do the generic check on these instructions in verifyInstruction any more. Should I add it back with explicit opcode checks? Or should we add a new operand flag to control the passing of address instead of matching the name?

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

Baremetal toolchain add Driver.SysRoot/include to the system include
paths without checking if Driver.SysRoot is empty. This resulted in
"-internal-isystem" "include" in the command. This patch adds check for
empty sysroot.

Reviewed By: jroelofs

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

This adds an initial test that can serve as a basis for other tests on
wrappergen.

Reviewed By: sivachandra

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

Make UnrollVectorPattern inherit from RewritePattern instead of
OpRewritePattern so that we don't need to create many patterns when applying to
many different type of ops. Since we may want to apply the pattern to all
arithmetic op, it is more convenient to filter dynamically.

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