APInt::toString() was removed rG61cdaf66

Some buildbots are complaining about std::move() after rG61cdaf66

Given `int foo, bar;`, TraverseAST reveals this tree:
  TranslationUnitDecl
   - foo
   - bar

Before this patch, with the TraversalScope set to {foo}, TraverseAST yields:
  foo

After this patch it yields:
  TranslationUnitDecl
  - foo

Also, TraverseDecl(TranslationUnitDecl) now respects the traversal scope.

---

The main effect of this today is that clang-tidy checks that match the
translationUnitDecl(), either in order to traverse it or check
parentage, should work.

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

<string> is currently the highest impact header in a clang+llvm build:

https://commondatastorage.googleapis.com/chromium-browser-clang/llvm-include-analysis.html

One of the most common places this is being included is the APInt.h header, which needs it for an old toString() implementation that returns std::string - an inefficient method compared to the SmallString versions that it actually wraps.

This patch replaces these APInt/APSInt methods with a pair of llvm::toString() helpers inside StringExtras.h, adjusts users accordingly and removes the <string> from APInt.h - I was hoping that more of these users could be converted to use the SmallString methods, but it appears that most end up creating a std::string anyhow. I avoided trying to use the raw_ostream << operators as well as I didn't want to lose having the integer radix explicit in the code.

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

See context: https://github.com/clangd/clangd/issues/765

Reviewed By: sammccall

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

Reviewed By: ulysseB

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

GCC documentation for the `wa` constraint states that:
```
wa

    A VSX register (VSR), vs0…vs63. This is either an FPR (vs0…vs31 are f0…f31)
    or a VR (vs32…vs63 are v0…v31).
```
This technically means that we could accept floating point parameters. In fact,
gcc itself does. The following testcase compiles and runs on all PPC platforms with GCC,
whereas clang/llc will assert:
```
#include <stdio.h>
double foo ( vector double a ) {
  double b, c;
  asm("xvabsdp  %x0, %x2        \n"
             "xxsldwi  %x1, %x0, %x0, 2 \n"
      :  "+wa"    (b),
         "=wa"    (c)
      :  "wa"    (a)
      );
  return b+c;
}
int main(void) {
  vector double a = {-3., -4.};
  double t = foo( a );
  printf("%g\n", t);
}
```
This patch allows clang/llc to build and run this testcase.

Reviewed By: nemanjai, #powerpc

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

mixed integer and floating point types with WarnOnEquivalentBitWidth=0.

Also standardize control flow of handleX conversion functions to make it easier to be consistent.

Patch by Stephen Concannon!

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

Noticed while updating D103888 - some of the tests were using "StringExtras" for the test_suite_name instead of the expected "StringExtrasTest"

Refactor to avoid assignment inside condition by using 'if
(init-decl)'.  Also remove some unnecessary braces on a separate
if-nest.

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

Re-applying this patch after bots failures. Should be fine now.

The function __multi3() is undefined on 32-bit ARM, so a call to it should
never be emitted. Instead, plain instructions need to be generated to
perform 128-bit multiplications.

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

Added a case for CTPOP to AArch64TTIImpl::getIntrinsicInstrCost so that
the cost estimate matches the codegen in
test/CodeGen/AArch64/arm64-vpopcnt.ll

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

This fixes the prioritization of address spaces when choosing a
constructor, stopping them from being considered equally good,
which made the construction of types that could be constructed
by more than one of the constructors.

It does this by preferring the most specific address space,
which is decided by seeing if one of the address spaces is
a superset of the other, and preferring the other.

Fixes: PR50329

Reviewed By: Anastasia

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

The previous implementation would accidentally still sort the individual
named imports, even if the module reference was in a clang-format off
block.

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

This has been reported several times by the PVS Studio team as well as coming up in some static analysis.

getRandom() % 1 always returns 0 so we never actually test this codepath, (git blame suggests this has always been like this) - given that we have plenty of other "getRandom() & 1" the typo is pretty obvious, and matches the intention in the comment above - with this change we generate a nice mixture of scalar/vector condition selects of vectors.

I don't know llvm-stress that well - but I don't think we guarantee that the same seed value will always generate the same IR for later versions of the program - just that the same binary would.

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

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

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

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

Whenever Tracker spawns a visitor that needs to call tracker
back, we have to use TrackingBugReporterVisitor in order to maintain
all the hooks that the checker might've used.

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

This component should not be used directly at this point and it is
simply an implementation detail, that's why StoreSiteFinder is
out of the header file.

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

Additionally, this commit completely removes any uses of
FindLastStoreBRVisitor from the analyzer except for the
one in Tracker.

The next step is actually removing this class altogether
from the header file.

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

This commit moves trackExpressionValue into the Tracker interface
as DefaultExpressionHandler.  It still can be split into smaller
handlers, but that can be a future change.

Additionally, this commit doesn't remove the original trackExpressionValue
interface, so it's not too big.  One of the next commits will address it.

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

Tracking values through expressions and the stores is fundamental
for producing clear diagnostics.  However, the main components
participating in this process, namely `trackExpressionValue` and
`FindLastStoreBRVisitor`, became pretty bloated.  They have an
interesting dynamic between them (and some other visitors) that
one might call a "chain reaction". `trackExpressionValue` adds
`FindLastStoreBRVisitor`, and the latter calls `trackExpressionValue`.

Because of this design, individual checkers couldn't affect what's
going to happen somewhere in the middle of that chain.  Whether they
want to produce a more informative note or keep the overall tracking
going by utilizing some of the domain expertise.  This all lead to two
biggest problems that I see:

  * Some checkers don't use it
  This should probably never be the case for path-sensitive checks.

  * Some checkers incorporated their logic directly into those
    components
  This doesn't make the maintenance easier, breaks multiple
  architecture principles, and makes the code harder to read adn
  understand, thus, increasing the probability of the first case.

This commit introduces a prototype for a new interface that will be
responsible for tracking.  My main idea here was to make operations
that I want have as a checker developer easy to implement and hook
directly into the tracking process.

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

This results in slightly more optimistic alignments in some cases

Adding support for __tile_stream_loadd intrinsic.

Reviewed By: LuoYuanke

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

We were passing the RecurrenceDescriptor by value to most of the reduction analysis methods, despite it being rather bulky with TrackingVH members (that can be costly to copy). In all these cases we're only using the RecurrenceDescriptor for rather basic purposes (access to types/kinds etc.).

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

Since 8866793b ("[OpenCL] Add OpenCL builtin test generator",
2021-06-09) there are two emitters in this file, so move the
file-level comment to the appropriate class.

[compiler-rt] [builtins] [AArch64] Add missing AArch64 data synchronization barrier (dsb) to __clear_cache

https://developer.arm.com/documentation/den0024/a/Caches/Cache-maintenance
covers how to properly clear caches on AArch64, and the builtin
implementation was missing a `dsb ish` after clearing the icache for the
selected range.

Reviewed By: kristof.beyls

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

There is a followup fix for a unit test introduced at D102906. The test file was placed into a temp folder and test assumed that it would be visible without the full path specification.

This behaviour can be changed in future and it would be good to specify full path to the file at the test.

Test Plan:
```
ninja check-clang-tools
```

Reviewed By: DmitryPolukhin

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

Create a ComplexUnaryOp base class and use it for AbsOp, ReOp and ImOp.
Sort all ops in lexicographic order.

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

This adds a function specialization pass to LLVM. Constant parameters
like function pointers and constant globals are propagated to the callee by
specializing the function.

This is a first version with a number of limitations:
- The pass is off by default, so needs to be enabled on the command line,
- It does not handle specialization of recursive functions,
- It does not yet handle constants and constant ranges,
- Only 1 argument per function is specialised,
- The cost-model could be further looked into, and perhaps related,
- We are not yet caching analysis results.

This is based on earlier work by Matthew Simpson (D36432) and Vinay Madhusudan.
More recently this was also discussed on the list, see:

https://lists.llvm.org/pipermail/llvm-dev/2021-March/149380.html.

The motivation for this work is that function specialisation often comes up as
a reason for performance differences of generated code between LLVM and GCC,
which has this enabled by default from optimisation level -O3 and up. And while
this certainly helps a few cpu benchmark cases, this also triggers in real
world codes and is thus a generally useful transformation to have in LLVM.

Function specialisation has great potential to increase compile-times and
code-size.  The summary from some investigations with this patch is:
- Compile-time increases for short compile jobs is high relatively, but the
  increase in absolute numbers still low.
- For longer compile-jobs, the extra compile time is around 1%, and very much
  in line with GCC.
- It is difficult to blame one thing for compile-time increases: it looks like
  everywhere a little bit more time is spent processing more functions and
  instructions.
- But the function specialisation pass itself is not very expensive; it doesn't
  show up very high in the profile of the optimisation passes.

The goal of this work is to reach parity with GCC which means that eventually
we would like to get this enabled by default. But first we would like to address
some of the limitations before that.

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

This reverts commit 9625d61e since
libc++ currently has issues with disabled exceptions which breaks
the runtimes build.