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

Reviewed By: Mordante, #libc

Spies: libcxx-commits

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

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

This change adds `allErased` to the `applyOpPatternsAndFold(ArrayRef<Operation *>, ...)` overload. This overload now supports all functionality that is also supported by `applyOpPatternsAndFold(Operation *, ...)` and can be used as a replacement.

This change has no performance implications when `allErased = nullptr`.

The single-operation overload is removed in a subsequent NFC change.

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

Reviewed By: clementval

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

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

Current implementation uselessly calls memset on its internal buffer
while it does not read the non overwritten part.

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

This reverts commit 00e967f6.

This breaks builders where long is only 32 bits, e.g.
https://lab.llvm.org/buildbot/#/builders/65/builds/7721
https://lab.llvm.org/buildbot/#/builders/245/builds/3899

classifyPrim() runs into a llvm_unreachable() for those.

We were just casting to `unsigned` before, so that caused problems when
shifting more bits than `unsigned` has.

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

isVectorConstantLegal calls findFirstSet and findLastSet, but we don't
rely on their ability to return std::numeric_limits<T>::max() on input
0.

This patch replaces those calls with calls to llvm::countl_zero and
llvm::countr_zero.

Due to an off-by-one error in the original code, the value of Upper
could change at bit N, where N is the index of the highest set bit in
SplatBitsZ, but the difference doesn't matter at the end.  Without
this patch, Upper could have bit N set.  With this patch, Upper never
has bit N set.  Either way, both calls to tryValue have this bit set
because the argument is ORed with SplatBitsZ.

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

For a nonzero argument, llvm::findLastSet(x) is equivalent to
llvm::Log2_32(x) or llvm::Log2_64(x).  None of the calls to
llvm::findLastSet in this patch relies on llvm::findLastSet's ability
to return std::numeric_limits<T>::max() on input 0.

partMSB and partLSB never get 0 as the argument.  That is, we don't
rely on find{First,Last}Set's ability to return
std::numeric_limits<T>::max() on input 0.

This patch replaces partLSB and partMSB with llvm::countr_zero and
llvm::Log2_64, respectively.

FWIW, nobody in LLVM (except unit test MathExtrasTest.cpp) relies on
find{First,Last}Set's ability to return std::numeric_limits<T>::max()
on input 0.

Reviewed By: barannikov88

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

loadImmediate computes ShiftAmount in an unnecessarily complicated
manner.  We just need to know the minimum right shift amount to bring
the immediate down to an unsigned 16-bit value, so

  unsigned ShiftAmount = llvm::bit_width((uint64_t)ImmValue) - 16;

is sufficient.  In other words, the following are all equivalent:

  unsigned ShiftAmount = FirstSet - (15 - (LastSet - FirstSet));
  unsigned ShiftAmount = llvm::countr_zero(IV) - (15 - (63 - llvm::countl_zero(IV) - llvm::countr_zero(IV)));
  unsigned ShiftAmount = llvm::countr_zero(IV) - 15 + (63 - llvm::countl_zero(IV) - llvm::countr_zero(IV));
  unsigned ShiftAmount = 48 - llvm::countl_zero(IV);
  unsigned ShiftAmount = 64 - llvm::countl_zero(IV) - 16;
  unsigned ShiftAmount = llvm::bit_width(IV) - 16;

where IV represents (uint64)ImmValue.  I've also checked the
equivalence empirically up to 2u << 32.

isShiftedUIntAtAnyPosition never gets zero as the argument because the
caller processes ImmValue satisfying isInt<16>(ImmValue), which
includes zero, long before it calls isShiftedUIntAtAnyPosition.

Given that the argument is always nonzero, findFirstSet is identical
to llvm::countr_zero.  Also, x == x >> BitNum << BitNum is always
true, so we are left with:

  isUInt<N>(x >> llvm::countr_zero(x))

Just in case the caller changes its behavior and starts passing zero
to us, we can protect the shift from undefined behavior "x << 64" by
adding "x &&".

This reverts commit efbc8bb1.

This change is causing failures when detecting curl on several build bots:
 - https://lab.llvm.org/buildbot/#/builders/247/builds/884
 - https://lab.llvm.org/buildbot/#/builders/231/builds/7688
 - https://lab.llvm.org/buildbot/#/builders/121/builds/27389
 - https://lab.llvm.org/buildbot/#/builders/230/builds/8464
 - https://lab.llvm.org/buildbot/#/builders/57/builds/24209
 - https://lab.llvm.org/buildbot/#/builders/127/builds/42722

This reverts commit 46013fc1.

The original commit efbc8bb1 is failing on several bots, so
reverting this follow-up commit as well as the original commit.