This header was transitively included to provide the definition of
__lc_ctype_ptr that we use on AIX, but that is fragile as it depends on
the settings of compatibility macros, so we explicitly include it here
to avoid that scenario.

Reviewed By: #libc, ldionne

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

Some random changes that were hanging around in my workspace. Also,
a tiny step towards creating a header file for the sparse utils lib.

Reviewed By: bixia

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

Reviewed By: nicolasvasilache

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

After CMake 3.18, we are able to limit the scope of the search to just
Development.Module. Searching for Development will fail in situations
where the Python libraries are not available. When possible, limit to
just Development.Module. See:
https://pybind11.readthedocs.io/en/stable/compiling.html#findpython-mode

Reviewed By: stellaraccident

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

While looking at LWG-2988 and P0558 it seems the issues were already
implemented, but the synopsis wasn't updated. Some of the tests didn't
validate the `noexcept` status. A few tests were missing completely:
- `atomic_wait_explicit`
- `atomic_notify_one`
- `atomic_notify_all`

Mark P0558 as complete, didn't investigate which version of libc++ first
includes this. It seems the paper has been retroactively applied. I
couldn't find whether this is correct, but looking at cppreference it
seems intended.

Completes
- LWG-2988 Clause 32 cleanup missed one typename
- P0558 Resolving atomic<T> named base class inconsistencies

Reviewed By: #libc, ldionne

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

This allows picking up on mingw triples that often use 'w64' instead
of 'pc' as the vendor part.

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

This reverts commit 66e13c7f.

It was committed by accident.

With the -early-live-intervals command line flag,
TwoAddressInstructionPass::runOnMachineFunction would call
MachineFunction::verify before returning to check the live intervals.
But there was not much benefit to doing this since -verify-machineinstrs
and LLVM_ENABLE_EXPENSIVE_CHECKS provide a more general way of
scheduling machine verification after every pass.

Also it caused problems on targets like Lanai which are marked as "not
machine verifier clean", since verification would fail for known
target-specific problems which are nothing to do with LiveIntervals.

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

This has a couple of benefits:
1. It can sometimes fix clusters that got broken apart when the register
   allocator inserted a copy.
2. Post-RA scheduling does not have to worry about increasing register
   pressure, which in some cases gives it more freedom to reorder
   instructions.

Testing on a collection of 10,000 graphics shaders compiled for gfx1010
showed:
- The average length of each run of one or more load instructions
  increased by about 1%.
- The number of runs of two or more load instructions increased by
  about 4%.

This patch shifts the InstrRefBasedLDV class declaration to a header.
Partially because it's already massive, but mostly so that I can start
writing some unit tests for it. This patch also adds the boilerplate for
said unit tests.

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

Add a switch to code gen strategy to disable/enable the vector transfer lowering and disable it by default.

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

Depends on D111135

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

This is the second part of p0388, dealing with overloads of list
initialization to incomplete array types.  It extends the handling
added in D103088 to permit incomplete arrays.  We have to record that
the conversion involved an incomplete array, and so (re-add) a bit flag
into the standard conversion sequence object.  Comparing such
conversion sequences requires knowing (a) the number of array elements
initialized and (b) whether the initialization is of an incomplete array.

This also updates the web page to indicate p0388 is implemented (there
is no feature macro).

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

This implements the new implicit conversion sequence to an incomplete
(unbounded) array type.  It is mostly Richard Smith's work, updated to
trunk, testcases added and a few bugs fixed found in such testing.

It is not a complete implementation of p0388.

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

The list of checked functions was incomplete in the description.

Reviewed By: aaron.ballman, steakhal

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

Add the vector transfer patterns and introduce the max transfer rank option on the codegen strategy.

Reviewed By: nicolasvasilache

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

Add necessary typemaps for Lua bindings, together with some other files.

Signed-off-by: Siger Yang <sigeryeung@gmail.com>

Reviewed By: tammela

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

This requirement was introduced in the C++ Core guidelines in 2016:

https://github.com/isocpp/CppCoreGuidelines/commit/1894380d0abf4d7d49a983005647e0d41ecbf214

Then clang-tidy got updated to comply with the rule.

However in 2019 this decision was reverted:

https://github.com/isocpp/CppCoreGuidelines/commit/5fdfb20b760c5307bf86873798a146fcd7e912e6

Therefore we need to apply the correct configuration to
clang-tidy again.

This also makes this cppcoreguidelines check consistent
with the other 2 alias checks: hicpp-use-override and
modernize-use-override.

Additionally, add another RUN line to the unit test,
to make sure cppcoreguidelines-explicit-virtual-functions
is tested.

This patch allows MMA built-ins on PowerPC to accept restrict
and volatile qualified pointers.

Reviewed By: #powerpc, nemanjai

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

Due to CMake cache, find_package in FindLuaAndSwig.cmake
will be ignored. This commit adds EXACT and REQUIRED flags
to it and removes find_package in Lua ScriptInterpreter.

Signed-off-by: Siger Yang <sigeryeung@gmail.com>

Reviewed By: tammela, JDevlieghere

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

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

Adjust the encoding and format applied to i387_ext and vec* type
registers from gdbserver to match lldb-server.  Both types are now
displayed as vector of uint8 instead of float and integer formats used
before.  Additionally, this fixes display of STi registers when they do
not carry floating-point data (they are also used to hold MMX vectors).

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

`[[clang::fallthrough]]` has meaning for the CFG, but all other
StmtAttrs we currently have don't. So omit them, as AttributedStatements
with children cause several issues and there's no benefit in including
them.

Fixes PR52103 and PR49454. See PR52103 for details.

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

This revision takes advantage of the recently added support for 0-d transfers and vector.multi_reduction that return a scalar.

Reviewed By: pifon2a

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

* Fold extract_slice immediately after insert_slice.
* Fold overlapping insert_slice.

Reviewed By: ThomasRaoux

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

This revision also renames and moves some tests around.

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

Reviewed By: pifon2a

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

collectLoopScalars collects pointer induction updates in ScalarPtrs, assuming
that the instruction will be scalar after vectorization. This may crash later
in VPReplicateRecipe::execute() if there there is another user of the instruction
other than the Phi node which needs to be widened.

This changes collectLoopScalars so that if there are any other users of
Update other than a Phi node, it is not added to ScalarPtrs.

Reviewed By: david-arm, fhahn

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

This revision updates the op semantics, printer, parser and verifier to allow 0-d transfers.
Until 0-d vectors are available, such transfers have a special form that transits through vector<1xt>.
This is a stepping stone towards the longer term work of adding 0-d vectors and will help significantly reduce corner cases in vectorization.

Transformations and lowerings do not yet support this form, extensions will follow.

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

[mlir][Linalg] NFC - Refactor vector.broadcast op verification logic and make it available as a precondition in Linalg vectorization.

Reviewed By: pifon2a

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

Using contains was suggested in D108114, but I forgot to include it when
landing the patch.

vector.multi_reduction currently does not allow reducing down to a scalar.
This creates corner cases that are hard to handle during vectorization.
This revision extends the semantics and adds the proper transforms, lowerings and canonicalizations to allow lowering out of vector.multi_reduction to other abstractions all the way to LLVM.

In a future, where we will also allow 0-d vectors, scalars will still be relevant: 0-d vector and scalars are not equivalent on all hardware.

In the process, splice out the implementation patterns related to vector.multi_reduce into a new file.

Reviewed By: pifon2a

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

`hint-expression` is an IntegerAttr, because it can be a combination of multiple values from the enum `omp_sync_hint_t` (Section 2.17.12 of OpenMP 5.0)

Reviewed By: ftynse, kiranchandramohan

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

This is a follow up of D110529 that disallowed constexprs. That change
introduced a regression as this also disallowed constexprs that are function
pointers, which is actually one of the motivating use cases that we do want to
support.

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

This patch adds a new cost heuristic that allows peeling a single
iteration off read-only loops, if the loop contains a load that

    1. is feeding an exit condition,
    2. dominates the latch,
    3. is not already known to be dereferenceable,
    4. and has a loop invariant address.

If all non-latch exits are terminated with unreachable, such loads
in the loop are guaranteed to be dereferenceable after peeling,
enabling hoisting/CSE'ing them.

This enables vectorization of loops with certain runtime-checks, like
multiple calls to `std::vector::at` if the vector is passed as pointer.

Reviewed By: mkazantsev

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

To reduce the number of explicit builds of a single module, we can try to squash multiple occurrences of the module with different command-lines (and context hashes) by removing benign command-line options. The greatest contributors to benign differences between command-lines are the header search paths.

In this patch, the lookup cache in `HeaderSearch` is used to identify paths that were actually used when implicitly building the module during scanning. This information is serialized into the unhashed control block of the implicitly-built PCM. The dependency scanner then loads this and may use it to prune the header search paths before computing the context hash of the module and generating the command-line.

We could also prune the header search paths when serializing `HeaderSearchOptions` into the PCM. That way, we could do it only once instead of every load of the PCM file by dependency scanner. However, that would result in a PCM file whose contents don't produce the same context hash as the original build, which is probably highly surprising.

There is an alternative approach to storing extra information into the PCM: wire up preprocessor callbacks to capture the used header search paths on-the-fly during preprocessing of modularized headers (similar to what we currently do for the main source file and textual headers). Right now, that's not compatible with the fact that we do an actual implicit build producing PCM files during dependency scanning. The second run of dependency scanner loads the PCM from the first run, skipping the preprocessing altogether, which would result in different results between runs. We can revisit this approach when we stop building implicitly during dependency scanning.

Depends on D102923.

Reviewed By: dexonsmith

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