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

If inlining into an LLVM function, move allocas of constant size from
the callee's entry block to the new entry block, as this will fold into
the prologue/epilogue code during code generation.

We still allow inlining allocas even if we cannot do this
post-processing (i.e., when we are not inlining into an `LLVM::FuncOp`),
since this is an optimization (and thus not necessary for correctness).

Depends on D141682

Reviewed By: gysit

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

Even if the intrinsic is supported by ConstantRange, we should
still make use of !range metadata. This doesn't matter much now,
but is important if we want to support ctlz style intrinsics,
which always have KnownBits-based !range metadata attached, which
might be better than what we can compute using ranges.

(X s>> BitWidth - 1) == sext (Y s> -1) --> (X ^ Y) < 0
(X s>> BitWidth - 1) != sext (Y s> -1) --> (X ^ Y) > -1

This is the same logic as:
7cbfc39c
...extended to deal with "signed" cast+shift instructions.

https://alive2.llvm.org/ce/z/LLidya

This was added recently with:
e44a3056

These are copied from the zext+lshr variants from:
e76c95fb
d1511ed8

This folder contains the kernel and notebooks
so let's make that obvious and list them in the
readme.

There are a lot of conventions for writing tests that don't seem
to be documented anywhere right now, so this takes a stab at
writing down some "best practices".

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

This reverts commit ce4fcea5.

I committed it accidentally.

The CPUs never supported SM4 instructions, but until recently I think crypto
was folded into the baseline architecture as a monolithic feature so it was
difficult to represent that. Now it's split we can, and the CPUs that support
v8.4 onwards only handle AES, SHA2, SHA3 by way of crypto instructions.

When working out whether we can see a compressible jump-table pattern during
ConstantIslands, we were stopping when we saw a debug instruction. Instead it's
better to keep iterating backwards to the first real instruction.

Check for single smax pattern against zero when converting from a
small enough float.

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

This is purely refactoring to remove some unecessary C++ code.

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

This tutorial uses the dump json option to write a backend for
SQL queries.

It is based on the work of Min-Yih Hsu:
* https://github.com/mshockwave/SQLGen
* https://www.youtube.com/watch?v=UP-LBRbvI_U

I hope that having the same concepts in 3 forms will allow people
to choose the style that fits them.

The main drawback here being that it's in Python. C++ can be used
in a notebook (https://github.com/jupyter-xeus/xeus-cling) but I
decided against it for a few reasons:

* Python is the default for Jupyter, no extra installs needed.
* Having the code in a second language may help people who
  know one or the other.
* There is no upstream example of a JSON powered backend.
  (and although we would be unlikely to accept one upstream,
  I think it's a great option for quick development before
  translating into C++)

Reviewed By: myhsu

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

When lowering predicate permute builtins we incorrectly assume only
the typically "active" bits for the specified element type play a
role with all other bits zero'd.  This is not the case because all
bits are significant, with the element type specifying how they
are grouped:

  b8  - permute using a block size of 1 bit
  b16 - permute using a block size of 2 bits
  b32 - permute using a block size of 4 bits
  b64 - permute using a block size of 8 bits

The affected builtins are svrev, svtrn1, svtrn2, svuzp1, svuzp2,
svzip1 and svzip2.

This patch adds new intrinsics to support these operations and
changes the builtin lowering code to emit them.  The b8 case remains
unchanged because for that operation the existing intrinsics work
as required and their support for other predicate types has been
maintained as useful if only as a way to test the correctness of
their matching ISD nodes that code generation relies on.

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

This reverts commit f9010385.

This reverts commit 531756b9.

The recommitted version fixes a crash when one of the operands is a
constant other than a ConstantInt. Test for that case have been added
in 5b16cd97.

It splits off the new logic into a separate function because setting the
flags is quite different compared to the other cases handled in replaceSignedInst
which all require replacing an existing instruction.

It also guards makeGuaranteedNoWrapRegion by `if (!Inst.hasNoUnsignedWrap())`
as discussed in the review.

Fixes #60280.
Fixes #60278.

Original message:
    This patch updates SCCP to use the value ranges of AddInst operands to
    try to prove the AddInst does not overflow in the unsigned sense and
    adds the NUW flag. The reasoning is done with
    makeGuaranteedNoWrapRegion (thanks @nikic for point it out!).

    Follow-ups will include adding NSW and extension to more
    OverflowingBinaryOperators.

    Reviewed By: nikic

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

P1787: "CWG1960 (currently closed as NAD) is resolved by removing the rule in question (which is widely ignored by implementations and gives subtle interactions between using-declarations)."
Wording: "In a using-declarator that does not name a constructor, every declaration named shall be accessible."

Reviewed By: #clang-language-wg, erichkeane, shafik

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

To match up with the pseudo instruction names

Reviewed By: craig.topper

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

Adds IR intrinsics for the following SME2 instructions:
 - sqrshr (2 and 4 vector)
 - uqrshr (2 and 4 vector)
 - sqrshru (2 and 4 vector)
 - sqrshrn (4 vector)
 - uqrshrn (4 vector)
 - sqrshrun (4 vector)

Also adds intrinsics for the following SVE2p1 instructions:
 - sqrshrn (2 vector)
 - uqrshrn (2 vector)
 - sqrshrun (2 vector)

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

Reviewed By: CarolineConcatto

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

This patch adds Fortran Lowering support for the OpenMP Target Data, Target Exit Data and Target Enter Data constructs.
operation.

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

Fix these build warnings:

SPIRVBuiltins.cpp:1590:30: warning: 'getPrefTypeAlignment' is deprecated: use getPrefTypeAlign instead [-Wdeprecated-declarations]
SPIRVUtils.cpp:209:3: warning: default label in switch which covers all enumeration values [-Wcovered-switch-default]

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

Adds intrinsics for the following SME2 instructions:
 - sqdmulh, 2 vector (single & multi)
 - sqdmulh, 4 vector (single & multi)

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

Reviewed By: david-arm

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

This removes typed pointer support in a prominent place in the
optimization pipeline, to ensure that any non-trivial consumers
of tip-of-tree LLVM are aware that this is no longer a supported
configuration.

This reverts commit e70ca7b3 and the
followup patch "[clang] Fix the location of UsingTypeLoc"
(ebbeb164).

The patch causes an incorrect lookup result:

```
namespace ns { struct Foo { };}

using ns::Foo;
void test() {
  struct Foo {
  } k; // the type of k refers to ns::Foo, rather than the local Foo!
}
```

These are all tests that end up running SROA.

Run update_llc_test_checks on a number of codegen tests.

The key part of getRawCommentForDecl() required to find a comment
is determining where to look for it. The location of the decl
itself is usually right, except when macros get involved. The
comment in the macro is stored in RawCommentList at the spelling
location of the decl, not at the place where the decl comes into
being as the macro is instantiated.

getDeclLocForCommentSearch() already contained to branches to try
handle comments inside macros, and we are able to replace them
and handle more cases as well, by returning the spelling location
of the decl's begin location. That is:
  SourceMgr.getSpellingLoc(D->getBeginLoc())

Reviewed By: gribozavr2

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