Reviewed By: eugenis

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

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

This reverts commit db7a87ed.

This seems to cause a PPC buildbot failure:
https://lab.llvm.org/buildbot#builders/93/builds/8787

Since D97044, libc++ implements <stdatomic.h>, which is not compatible
with the <atomic> header in C++03 mode. To fix the tests, avoid using
<stdatomic.h> at all, since it is not strictly required.

rdar://92867529

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

This only adds the customization point object (which isn't pipeable),
the view itself has already been implemented previously.

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

This patch adds a test case for i256 additions and subtractions.  I'm
leaving out multiplications for now, which would result in very long
sequences.

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

The view itself has been implemented previously -- this patch only adds
the ability to pipe it.

Also implements [P1739](https://wg21.link/p1739) (partially) and [LWG3407](https://wg21.link/lwg3407).

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

This change was intended to add the tests check-clang and check-clang-pseudo,
but afterwards it was *only* running those tests.
(This was because unlike add_lit_testsuite, add_lit_testsuite*s* does not
get included in umbrella suites).

This is the idiomatic way to handle include directories in CMake.

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

This changes the ELFNix platform Orc runtime to use, when available,
the __unw_add_dynamic_eh_frame_section interface provided by libunwind
for registering .eh_frame sections loaded by JITLink. When libunwind
is not being used for unwinding, the ELFNix platform detects this and
defaults to the __register_frame interface provided by libgcc_s.

Reviewed By: lhames

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

Currently we require the `-fopenmp-targets=` option to specify the
triple to use for the offloading toolchains, and the `-Xopenmp-target=`
option to specify architectures to a specific toolchain. The changes
made in D124721 allowed us to use `--offload-arch=` to specify multiple
target architectures. However, this can become combersome with many
different architectures. This patch introduces functinality that
attempts to deduce the target triple and architectures from the
offloading action. Currently we will deduce known GPU architectures when
only `-fopenmp` is specified.

This required a bit of a hack to cache the deduced architectures,
without this we would've just thrown an error when we tried to look up
the architecture again when generating the job. Normally we require the
user to manually specify the toolchain arguments, but here they would
confict unless we overrode them.

Depends on: D124721

Reviewed By: saiislam

Differentia...

This patch adds support for OpenMP to use the `--offload-arch` and
`--no-offload-arch` options. Traditionally, OpenMP has only supported
compiling for a single architecture via the `-Xopenmp-target` option.
Now we can pass in a bound architecture and use that if given, otherwise
we default to the value of the `-march` option as before.

Note that this only applies the basic support, the OpenMP target runtime
does not yet know how to choose between multiple architectures.
Additionally other parts of the offloading toolchain (e.g. LTO) require
the `-march` option, these should be worked out later.

Reviewed By: tra

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

This was leftover from when the standard dialect was destroyed, and
when FuncOp moved to the func dialect. Now that these transitions
have settled a bit we can drop these.

Most updates were handled using a simple regex: replace `^( *)func` with `$1func.func`

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

For the unary shuffle pattern, this is opposite to what we try
to do with binops, but it seems better to keep it consistent
with the motivating binary shuffle pattern. On that, it is
clearly better on the usual no-extra uses case.

There is a chance that this will pull an fneg away from some
other binop and cause a regression in codegen, but that should
be invertible in the backend. The transform is birectional:
https://alive2.llvm.org/ce/z/kKaKCU
https://alive2.llvm.org/ce/z/3Desfw

Fixes #45631

issue #45631

This reverts commit 324d696c.
Broke check-llvm on Windows, see e.g.
https://lab.llvm.org/buildbot/#/builders/216/builds/4005 and
comment on https://reviews.llvm.org/rG324d696c154aad42b2580d2f225a677c04fe0ab4

When targeting cortex-a53, set this linker flag rather than relying
on the toolchain users to do it in their build.

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

If the income state hasn't changed, and the step function is fixed by assumption, then the output state can't have changed.

In the current algorithm, this is a very minor win and mostly allows adding tracing output without being horrible verbose.

Only available with -debug.  Main purpose is simplifying an upcoming change, and providing tools for debugging problems.

This reverts commit 891c3cf9 as it turns
out that the error was not caused by this commit, the error caming
from D124526 instead.

That makes it possible to reuse libc++abi targets from the libc++
configuration, which is necessary to allow major CMake simplifications.
As a fly-by fix, we also unify how compiler-rt ordering is handled so
it matches how libc++ and libc++abi are handled (compiler-rt always
ends up first).

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

The LLVM ThreadPool recently got the addition of the concept of
ThreadPoolTaskGroup: this is a way to "partition" the threadpool
into a group of tasks and enable nested parallelism through this
grouping at every level of nesting.
We make use of this feature in MLIR threading abstraction to fix a long
lasting TODO and enable nested parallelism.

Reviewed By: rriddle

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

This patch is a followup to the previous patch which implemented the
main printf parsing logic as well as sequential mode. This patch adds
index mode.

Reviewed By: sivachandra

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

This check verifies the safety of access to `std::optional` and related
types (including `absl::optional`). It is based on a corresponding Clang
Dataflow Analysis, which does most of the work. This check merely runs it and
converts its findings into diagnostics.

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

fcgl option will make compilation stop after clang codeGen and output the llvm ir.
It is added to check clang codeGen output for HLSL.

It will be translated into -S -emit-llvm and -disable-llvm-passes.

Reviewed By: aaron.ballman

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

The entrypoint list for windows hasn't been updated in a while, this
adds all of the entrypoints that are working for windows now.

Reviewed By: sivachandra, lntue

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

This testcase runs slowly due to 3.2s of sleeps = 2 + 1 + 0.2s.
After this patch it has 0.55s only.

Reduced by:
 - observed that the last test was bogus: we were sleeping until the queue was
   idle, effectively just a second copy of the first test. This avoids 1s sleep.
 - when waiting for debounce, sleep only until test passes, not for enough
   time to be safe (in practice was 2x debounce time, now 1x debounce time)
 - scaling delays down by a factor of 2 (note: factor of 10 caused bot failures)

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