Summary:
Clang doesn't warn on `-B` options passed to it. This one is not
forwarded to the linker which results in some tests failing when
offloading to x86_64 with the `bfd` linker.

Reviewed By: gulfem

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

This patch add the instructions of Zcb extension.

Instructions in zcb extensions shorten part of bit manipulation instructions.

Co-authored-by: Craig Topper <craig.topper@sifive.com>

Reviewed By: craig.topper

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

This patch removes findFirstSet and findLastSet as there are no uses
left in LLVM.

I am not aware of any uses of findFirstSet and findLastSet in the
open-source world outside LLVM, so I am skipping the deprecation step.

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

This strips out about 5k symbols.

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

Reviewed By: john.brawn

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

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

They are not needed in <new> -- in fact they are only needed in .cpp files.
Getting those out of the way makes the headers smaller and also makes it
easier to use the library on platforms where aligned allocation is not
available.

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

https://reviews.llvm.org/D142405 made this function relying on the
LLVM_NATIVE_ARCH be defined, which is not necessarily the case for
third-party projects that include LLVM as their part.

Reviewed By: beanz

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

This patch updates examples in the documentation to match the existing
convention. Calls to intrinsics that have metadata arguments were not
included.

Reviewed By: dexonsmith

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

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

The assumption that generic pointers passed to a CUDA kernel is CUDA-specific
and should not be applied to non-CUDA compilations.  Addrspacecasts to global AS
and back should never be applied to AS-specific pointers.

In order to make tests actually do the testing for non-CUDA compilation, we need
to get TargetMachine from the TargetPassConfig, instead of passing it explicitly
as a pass constructor argument.

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

The `OpenMPOpt` pass is pivotal to the performance of many OpenMP
offloading programs. When we perform non-LTO builds with OpenMP we used
to link the OpenMP deviceRTL individually for each TU. This lead to us
getting an additional attributor run on the combined runtime and user
code. When we used LTO we lost a run and suffered a large performance
degradation. This patch simply adds in the extra `OpenMPOpt` pass that
we miss into the LTO pipeline. This patch fixes the performance
regression shown in applications that used OpenMP offloading in LTO
mode.

Previously, this wasn't legal to do as we could emit new runtime calls
into the module. That was fixed by D142646.

Depends on D142646

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

Reviewed By: jdoerfert

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

The `OpenMPOpt` pass contains optimizations that generate new calls into
the OpenMP runtime. This causes problems if we are in a state where the
runtime has already been linked statically. Generating these new calls
will result in them never being resolved. We should indicate if we are
in a "post-link" LTO phase and prevent OpenMPOpt from generating new
runtime calls.

Generally, it's not desireable for passes to maintain state about the
context in which they're called. But this is the only reasonable
solution to static linking when we have a pass that generates new
runtime calls.

Reviewed By: jdoerfert

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

is enabled.
In fast math mode some floating-point optimizations are performed such as
reassociation and distribution.

For example, the compiler may transform (a+b)+c into a+(b+c). Although these
two expressions are equivalent in integer arithmetic, they may not be in
floating-point arithmetic. The builtin tells the compiler that the expression
in parenthesis can’t be re-associated or distributed.
__arithmetic_fence(a+b)+c is not equivalent to a+(b+c).

This patch adds the support of the builtin to SPIR target.

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

As came up in the discussion on
https://reviews.llvm.org/rG12cb1cb3720de8d164196010123ce1a8901d8122

We were asserting because the attempt to print a note found that our
source range for a immediately declared constraint (as a part of
Parameter Mapping Substitution) wasn't in order.

However, it doesn't really make sense to have the location of this be
the whole list of template arguments, as that would result in the range
being:
bool func(std::thing<char*> auto foo) {}
                     ^^^^^^^^^^^^^^^

Even if done correctly.  Instead, this patch makes the range be just
'foo' in this case (or a pointer right after 'auto' if unnamed).

Reviewed By: asbirlea

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

Summary:
These comments are confusing as the `clang-offload-bundler` is no longer
used by these toolchains.

Change https://reviews.llvm.org/D140059 exposed the following crash in
Z3Solver, where bit widths were not checked consistently with that
change. This change makes the check consistent, and fixes the crash.

```
clang: <root>/llvm/include/llvm/ADT/APSInt.h:99:
  int64_t llvm::APSInt::getExtValue() const: Assertion
  `isRepresentableByInt64() && "Too many bits for int64_t"' failed.
...
Stack dump:
0. Program arguments: clang -cc1 -internal-isystem <root>/lib/clang/16/include
  -nostdsysteminc -analyze -analyzer-checker=core,unix.Malloc,debug.ExprInspection
  -analyzer-config crosscheck-with-z3=true -verify reproducer.c

 #0 0x00000000045b3476 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
  <root>/llvm/lib/Support/Unix/Signals.inc:567:22
 #1 0x00000000045b3862 PrintStackTraceSignalHandler(void*)
  <root>/llvm/lib/Support/Unix/Signals.inc:641:1
 #2 0x00000000045b14a5 llvm::sys::RunSignalHandlers()
  <root>/llvm/lib/Support/Signals.cpp:104:20
 #3 0x00000000045b2eb...

https://alive2.llvm.org/ce/z/7J8Exr

This is a commuted variant that was not included in:
D138853 / f2973327

Existing tests were added with D138853, but that patch failed
to handle all of the commutes. The poison-safety behavior is
symmetric, so I'm not duplicating all of the tests that were
added with that patch.

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

Review: Ulrich Weigand

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

Reviewed By: phosek

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

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

Found by PVS-Studio - https://pvs-studio.com/en/blog/posts/cpp/1003/, N18.
The value of the 'sourceDim' index is checked after it was used.

Reviewed By: zero9178

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

The check for the outer lowering wasn't quite right.

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

Add the following intrinsic:

 ADD vectors

NOTE: These intrinsics are still in development and are subject to future changes.

Reviewed By: david-arm

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

The traces are printed only for bottom-up and top-down scheduling
because the values of TopReadyCycle and BottomReadyCycle are
inconsistent when obtained via bidirectional scheduling (see
`BIDIRECTIONAL` checks in the test).

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

This allows much better verification messages in consuming ops that properly declare
`TransformHandleTypeInterface` on their operands.

Downstream tests can be updated with a command resembling:

```
 git grep -l "structured\.match" mlir/test | xargs -i sed -i {} -e  "s/\(structured.match.*\)/\1 : (\!pdl.operation) -> \!pdl.operation/g"
```

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

Basically NFC: A TEST/TEST_F/etc that bails out early (usually because
setup failed or some other runtime condition wasn't met) generally
should use GTEST_SKIP() to report its status correctly, unless it
takes steps to report another status (e.g., FAIL()).

In the handling of the Symbols from the RangExpr, the code assumed that
the operands of the unary operators need to have integral type.
However, the CSA can create SymExpr with a floating point operand, when
the integer value is cast into it, like `(float)h == (float)l` where
both of `h` and `l` are integers.

This patch handles such situations, by using `fromFloatUnOp()` instead
of `fromUnOp()`, when the operand have a floating point type.

I have investigated all other calls of `fromUnOp()`, and for one in:

 - `getZeroExpr()` is applied only on boolean types, so it correct
 - `fromBinOp()` is not invoked for floating points
 - `fromFloatUnOp()` I am uncertain about this case and I was not able
   to produce a test that would reach this point, as a negation of
   floating points numbers seem to produce `Unknown` symbols.

This issue exists since the introduction of `UnarySymExpr` in D125318
and their handling for Z3 in D125547.

Patch by Tomasz Kamiński.

Reviewed By: mikhail.ramalho

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

Fix assertion failure "PathDiagnosticSpotPiece's must have a valid location." in ReturnPtrRange checker on builtin functions

Builtin functions (such as `std::move`, `std::forward`, `std::as_const`)
have a body generated during the analysis not related to any source file
so their statements have no valid source locations.
`ReturnPtrRange` checker should not report issues for these builtin
functions because they only forward its parameter and do not create any
new pointers.

Fixes #55347

Patch by Arseniy Zaostrovnykh.

Reviewed By: NoQ

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

Ensure it is at least 8 bits.

Fixes #59801

Reviewed By: erichkeane

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

The auto-generated check lines for the test are missing `align`.
Re-generate the check lines to avoid unrelated changes in upcoming
change.

Add missing setValue calls in SelectionDAGBuilder for mem-transfer
intrinsic calls. These setValue calls are required in order to propagate
pcsections metadata from IR to MIR.

Reviewed By: melver

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

When adding pcsections to SDNodes, recursively add them to all values of
the node as well.

Reviewed By: melver

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

The object is now correct by construction.

This is the 15th commit of a patch-set that aims to change the default policy
for RVV intrinsics from TAMU to TAMA.

Please refer to the cover letter in the 1st commit (D141573) for an
overview.

Depends on D141793.

Reviewed By: craig.topper

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

Explicitly link libdl this time.

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