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.

Also add missing assembler test for the valid cases.

The format this uses is CA. I think it may have once shared CS and
this didn't get renamed when that changed in D54302.

Follow up to https://reviews.llvm.org/D142522.  I forgot to push the
test changes, was caught only in the post-merge builds.

flang-new encounters an issue where its unable to invoke itself because the
install directory was missing from the program paths on AIX.

Reviewed By: w2yehia

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

implicit-arg-v5-opt.ll already covers this with more cases.

This is a follow up to D142182, to expose LocationAttrs through Python.

Reviewed By: ftynse

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

Reviewed By: brettw

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

This patch adds the last conversion for scanf, %p. It is set up to match
the %p implementation in our printf.

Reviewed By: sivachandra, lntue

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

To add the current position (%n) conversion, some reorganization needed
to be done. The "write a number to this pointer using the length
modifier" utilities and a couple other shared parsing functions have
been moved into converter_utils.h. This made implementing
current_pos_converter very simple.

Reviewed By: lntue

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