Some MVE instructions have qr variants that take a Q and R register,
splatting the R register for each lane. This is usually handled fine for
standard splats as we sink the splat into the loop and combine the
resulting dup into the qr instruction. It does not work for constant
splats though, as we generate a vmovimm or constant pool load instead.

This intercepts that, generating a vdup of the constant instead where we
can turn the result into a qr instruction variant.

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

They were being applied too narrowly (they didn't cover signed char *,
for instance), and too broadly (they covered SomeTemplate<char[6]>) at
the same time.

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

Replaced llvm:sort with llvm::stable_sort, this was failing on the bot with
expensive checks enabled.

Reviewed By: lhames

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

For aggregates, we need to store the element type to be able to
reconstruct the aggregate Address. This increases the size of this
packed structure (as the second value is already used for alignment
in this case), but I did not observe any compile-time or memory
usage regression from this change.

As requested in D115787, I've added a test for LLVMConstGEP2 and
LLVMConstInBoundsGEP2. However, to make this work in the echo test,
I also had to change a couple of APIs to work on GEP operators,
rather than only GEP instructions.

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

TOSA's canonicalizers that change dense operations should be moved to a
seperate optimization pass to avoid canonicalizing to operations not supported
for relevant backends.

Reviewed By: rsuderman

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

Fixes https://github.com/llvm/llvm-project/issues/42339

Reviewed By: phosek, sylvestre.ledru

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

This also makes the sanitizer_stoptheworld_test cross-platform by using the STL, rather than pthread.

Reviewed By: vitalybuka

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

When reading location lists in dwo files the addresses cannot be
resolved, but that's not a problem.

Long term this probably should be fixed with a different API that
exposes location expressions without the need to resolve the address
ranges, since that's all the verifier (in its current state) requires.
(though the verifier should probably also eventually verify the address
ranges in location lists are a subset of the enclosing scope's address
range)

sizeof(pieces) decreases from 24 to 16 on ELF64.
One BumpPtrAllocator can store more MergeInputSections.
The lld executable becomes smaller.

Only called once. Moving to OutputSections.cpp can make it inlined.
finalizeInputSections can be very hot, especially in -O1 links with much debug info.

When verifying dwo files address ranges won't be able to be resolved due
to missing debug_addr (or missing debug_ranges in the case of DWARFv4
Split DWARF).

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

`EnumAttr` is a pure TableGen implementation of enum attributes using `AttrDef`. This is meant as a drop-in replacement for `StrEnumAttr`, which is soon to be deprecated. `StrEnumAttr` is often used over `IntEnumAttr` because its more readable in MLIR assembly formats. However, storing and manipulating strings is not efficient. Defining `StrEnumAttr` can also be awkward and relies on a lot of special logic in `EnumsGen`, and has some hidden sharp edges.

Also, `EnumAttr` stores the enum directly,  removing the need to convert to/from integers when calling attribute getters on ops.

Reviewed By: mehdi_amini

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

Implement `getUnresolvedUsingType()` and don't create a new
`UnresolvedUsingType` when there is already canonical declaration.

This solved an incorrect ODR detection in modules for uresolved using
type.

Reviewed By: rjmccall

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

Since they refer to the debug_line in the skeleton unit, they can't be
resolved from the dwo CU.

But they can be resolved for split TUs, since those refer to
.debug_line.dwo, which is available in the dwo file.

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