This patch introduces the eviction analysis and the eviction advisor,
the default implementation, and the scaffolding for introducing the
other implementations of the advisor.

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

Revert "[analyzer][ctu] Fix wrong 'multiple definitions' errors caused by space characters in lookup names when parsing the ctu index file"

This reverts commit 333d66b0.
Breaks tests on macOS, see comments on https://reviews.llvm.org/D102669

Plan to use this in following change to support estimated trip counts derived from multiple loop exits.

This supports bitcode compilation using `clang -fwasm-exceptions`.

---

The current situation:

Currently the backend requires two options for Wasm EH:
`-wasm-enable-eh` and `-exception-model=wasm`. Wasm SjLj requires two
options as well: `-wasm-enable-sjlj` and `-exception-model=wasm`. When
using Wasm EH via Emscripten, you only need to pass `-fwasm-exceptions`,
and these options will be added within the clang driver. This
description will focus on the case of Wasm EH going forward, but Wasm
SjLj's case is similar.

When you pass `-fwasm-exceptions` to emcc and clang driver, the clang
driver adds these options to the command line that calls the clang
frontend (`clang -cc1`): `-mllvm -wasm-enable-eh` and
`-exception-model=wasm`. `-wasm-enable-eh` is prefixed with `-mllvm`, so
it is passed as is to the backend. But `-exception-model` is parsed and
processed within the clang frontend and stored in `LangOptions` class.
This info is later transferred to `TargetOptions` class, and then
eventually passed to `MCAsmInfo` class. All LLVM code queries this
`MCAsmInfo` to get the exception model.

---

Problem:

The problem is the whole `LangOptions` processing is bypassed when
compiling bitcode, so the information transfer of `LangOptions` ->
`TargetOptions` -> `MCAsmInfo` does not happen. They are all set to
`ExceptionHandling::None`, which is the default value.

---

What other targets do, and why we can't do the same:

Other targets support bitcode compilation by the clang driver, but they
can do that by using different triples. For example, X86 target supports
multiple triples, each of which has its own subclass of `MCAsmInfo`, so
it can hardcode the appropriate exception model within those subclasses'
constructors. But we don't have separate triples for each exception
mode: none, emscripten, and wasm.

---

What this CL does:

If we can figure out whether `-wasm-enable-eh` is passed to the backend,
we can programatically set the exception model from the backend, rather
than requiring it to be passed.

So we check `WasmEnableEH` and `WasmEnableSjLj` variables, which are
`cl::opt` for `-wasm-enable-eh` and `-wasm-enable-sjlj`, in
`WebAssemblyMCAsmInfo` constructor, and if either of them is set, we set
`MCAsmInfo.ExceptionType` to Wasm. `TargetOptions` cannot be updated
there, so we make sure they are the same later.

Fixes https://github.com/emscripten-core/emscripten/issues/15712.

Reviewed By: dschuff

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

Also reverts an attempt to fix the build errors https://reviews.llvm.org/D115911

The original diff https://reviews.llvm.org/D114566 causes some build
errors that I need to investigate.

https://lab.llvm.org/buildbot/#/builders/118/builds/7037

This reverts commit 95946d2f.

Reviewed By: kyulee

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

Windows has trouble deleting the executable due to permissions.

For some reason this did not fail to compile for me locally, but did
fail on one of the builders. Here is the error:

https://lab.llvm.org/buildbot/#/builders/58/builds/14969
```
/home/buildbot/as-builder-4/lld-x86_64-ubuntu-fast/llvm-project/llvm/lib/ProfileData/InstrProfCorrelator.cpp: In static member function ‘static llvm::Expected<std::unique_ptr<llvm::InstrProfCorrelator::Context> > llvm::InstrProfCorrelator::Context::get(std::unique_ptr<llvm::MemoryBuffer>, const llvm::object::ObjectFile&)’:
/home/buildbot/as-builder-4/lld-x86_64-ubuntu-fast/llvm-project/llvm/lib/ProfileData/InstrProfCorrelator.cpp:44:10: error: could not convert ‘C’ from ‘std::unique_ptr<llvm::InstrProfCorrelator::Context>’ to ‘llvm::Expected<std::unique_ptr<llvm::InstrProfCorrelator::Context> >’
   return C;
```

Reviewed By: kyulee

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

It is possible for the shift value to exceed the number of bits. In these
cases we can just multiply by zero. This is relatively rare occurence but
should be handled.

Reviewed By: not-jenni

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

When the input and output of a pool2d op are both 1x1, it can be canonicalized to a no-op

Reviewed By: rsuderman

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

Add a test to `llvm-dwarfdump` to simply test that the error messages
make sense when passing bad `.dSYM`s.

Reviewed By: clayborg

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

Extend `llvm-profdata` to read in a `.proflite` file and also a debug info file to generate a normal `.profdata` profile. This reduces the binary size by 8.4% when building an instrumented Clang binary without value profiling (164 MB vs 179 MB).

This work is part of the "lightweight instrumentation" RFC: https://groups.google.com/g/llvm-dev/c/r03Z6JoN7d4

Reviewed By: kyulee

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

Slight rename and better variable type usage in tosa.conv2d to
tosa.fully_connected lowering. Included disabling pass for padded
convolutions.

Reviewed By: not-jenni

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

There is no need to check the counters on `Counted` after destroying
elements in the range because these tests are not testing `destroy`.

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

Initial pass - follow-up patches to address various limitations (debug
ranges, location lists... )

Add the llvm flag `-debug-info-correlate` to attach debug info to instrumentation counters so we can correlate raw profile data to their functions. Raw profiles are dumped as `.proflite` files. The next diff enables `llvm-profdata` to consume `.proflite` and debug info files to produce a normal `.profdata` profile.

Part of the "lightweight instrumentation" work: https://groups.google.com/g/llvm-dev/c/r03Z6JoN7d4

The original diff https://reviews.llvm.org/D114565 was reverted because of the `Instrumentation/InstrProfiling/debug-info-correlate.ll` test, which is fixed in this commit.

Reviewed By: kyulee

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

previously, memcpy could get stuck in a loop, calling __builtin_memcpy
which would redirect to itself. This patch removes that path.

Reviewed By: gchatelet, sivachandra, lntue

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

needed to match revert of
rG2b4876157562: AMDGPU: Remove AMDGPUFixFunctionBitcasts pass

This reverts commit 7ca35522.

Offload abort in Nekbone

This reverts commit 2b487615.

This is a slight generalization of D115829. I noticed this while restructuring code for a follow up patch to perform the same optimizations in DSE.

If we have a call whose only visible effect is writing to an alloca, and we're removing the alloca anyways, we don't care if the call also reads from the same alloca. That read will be unobservable and thus doesn't block removal of the call.

Worth noting is that this observation generalizes for non-argument reads. It just happens that case reduces to a readonly call, and is already handled separately.

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

There were changes made to the linux version of this test that were not made for darwin
(see https://reviews.llvm.org/D115837) and this caused downstream failures.

Adding comment to this test to remind people to edit interface_symbols_darwin.cpp.
There is the reverse of this comment in the darwin file to remind us to edit the linux version already.

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

These symbols were introduced in https://reviews.llvm.org/D114558 but were not properly guarded for mac which caused downstream CI failures

Reviewed By: kubamracek, yln

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

Part of D115204

LSan (`ASAN_OPTIONS=detect_leaks=1`) is supported on macOS, but disabled
by default on Darwin (`SANITIZER_MAC`):
```
COMMON_FLAG(bool, detect_leaks, !SANITIZER_MAC, "Enable memory leak detection.")
```

We enable it here for ASan tests to prevent regressions (per comment).
However, LSan is not supported for the iOS simulator and the tests fail
when it is enabled.

Make this "Is macOS?" check more precise since the current one (`Darwin
&& x86_64`) has two issues:
 * Includes the simulators
 * Excludes macOS on Apple Silicon

This will allow us to (re)enable simulator testing on Green dragon to
give open source better feedback about sanitizer changes:
https://green.lab.llvm.org

rdar://86529234

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

https://github.com/llvm/llvm-project/issues/49184

clang-format doesn't handle the use of AttributeMacros where `[[unlikely]]` / `[[likely]]` could be used in `if` statements

This was not covered in the original commit {{D80144}}

Fixes #49184

Reviewed By: curdeius, owenpan

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

[Bazel] Add LLVM_BUILD_* variables to llvm-config.h to mirror ec37e0bb

Reviewed By: vitalybuka

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