Comparing those two `const char *` values relies on the assumption that both
strings were created by a ConstString. Let's check that assumption with an
assert as otherwise this code silently does nothing and that's not great.

Summary:
This patch adds codegen support for the ACLE builtin types added in:

  https://reviews.llvm.org/D62960

so that the ACLE builtin types are emitted as corresponding scalable
vector types in LLVM.

Reviewers: rsandifo-arm, rovka, rjmccall, efriedma

Reviewed By: efriedma

Subscribers: tschuett, kristof.beyls, hiraditya, rkruppe, psnobl, llvm-commits, cfe-commits

Tags: #clang, #llvm

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

.dynsym and .dynstr are allocatable and therefore normally are placed
before non-allocatable .strtab, .shstrtab, .symtab sections.
But we are placing them after currently what creates a mix of
alloc/non-alloc sections and does not look normal.

Differential revision: https://reviews.llvm.org/D74756

Reverting because this patch is causing ~20 llvm-test-suite failures on
a number of different bots:
* http://lab.llvm.org:8011/builders/clang-cmake-armv8-lld/builds/3366
* http://lab.llvm.org:8011/builders/clang-cmake-aarch64-lld/builds/8222
* http://lab.llvm.org:8011/builders/clang-cmake-x86_64-avx2-linux/builds/13275
* http://lab.llvm.org:8011/builders/clang-s390x-linux-lnt/builds/17213

This reverts commit cd2c5af6.

This is part of the work to remove SelectionDAG::GetDemandedBits and just use SimplifyMultipleUseDemandedBits.

Recent experiments raised some v_cvt_f32_ubyte*_e32 regressions, so I've added some additional abilities to performCvtF32UByteNCombine to help unpack byte data more aggressively.

We still don't remove all OR(SHL,SRL) patterns as some of the regenerated nodes don't get combined again, but we are getting closer.

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

Following on from the extra VADDV lowering, this extends things to
handle VADDLV which allows summing values into a pair of i32 registers,
together treated as a i64. This needs to be done in DAGCombine too as
the types are otherwise illegal, which is a fairly simple addition on
top of the existing code.

There is also a VADDLVA instruction handled here, that adds the incoming
values from the two general purpose registers. As opposed to the
non-long version where we could just add patterns for add(x, VADDV), the
long version needs to handle this early before the i64 has being split
into too many pieces.

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

Custom legalize non-power-of-2 and unaligned load and store for MIPS32r5
and older, custom legalize non-power-of-2 load and store for MIPS32r6.

Don't attempt to combine non power of 2 loads or unaligned loads when
subtarget doesn't support them (MIPS32r5 and older).

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

Improve legality checks for load and store, 4 byte scalar
load and store are now legal for all subtargets.
During regbank selection 4 byte unaligned loads and stores
for MIPS32r5 and older get mapped to gprb.
Select 4 byte unaligned loads and stores for MIPS32r5.
Fix tests that unintentionally had unaligned load or store.

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

On some targets, like SPARC, forming overflow ops is only profitable if
the math result is used: https://godbolt.org/z/DxSmdB
This patch adds a new MathUsed parameter to allow the targets
to make the decision and defaults to only allowing it
if the math result is used. That is the conservative choice.

This patch also updates AArch64ISelLowering, X86ISelLowering,
ARMISelLowering.h, SystemZISelLowering.h to allow forming overflow
ops if the math result is not used. On those targets using the
overflow intrinsic for the overflow check only generates better code.

Reviewers: nikic, RKSimon, lebedev.ri, spatel

Reviewed By: lebedev.ri

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

Summary:
Implements the following intrinsics:
 - @llvm.aarch64.sve.eorbt
 - @llvm.aarch64.sve.eortb
 - @llvm.aarch64.sve.pmullb.pair
 - @llvm.aarch64.sve.pmullt.pair

Reviewers: sdesmalen, c-rhodes, dancgr, cameron.mcinally, efriedma, rengolin

Reviewed By: efriedma

Subscribers: tschuett, kristof.beyls, hiraditya, rkruppe, psnobl, cfe-commits, llvm-commits

Tags: #llvm

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

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

With this patch lld recognizes ARM SBREL relocations.
R_ARM*_MOVW_BREL relocations are not tested because they are not used.

Patch by Tamas Petz

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

This should use -> instead of '.', but the fix-it functionality of
the expression evaluator saved us here. Let's use the proper syntax
in the first place as we don't want to test fix-its here.

This directory escaped the modularization effort it seems. Just adding
this to the Host module along with the other common headers, which should
make this code less likely to break under modules and speed up compilation.

We already make use of the VADDV vector reduction instruction for cases
where the input and the output start out at the same type. The MVE
instruction however will sum into an i32, so if we are summing a v16i8
into an i32, we can still use the same instructions. In terms of IR,
this looks like a sext of a legal type (v16i8) into a very illegal type
(v16i32) and a vecreduce.add of that into the result. This means we have
to catch the pattern early in a DAG combine, producing a target VADDVs/u
node, where the signedness is now important.

This is the first part, handling VADDV and VADDVA. There are also
VADDVL/VADDVLA instructions, which are interesting because they sum into
a 64bit value. And VMLAV and VMLALV, which are interesting because they
also do a multiply of two values. It may look a little odd in places as
a result.

On it's own this will probably not do very much, as the vectorizer will
not produce this IR yet.

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

The tests added in D74425/commit a71feda2
fail with an assertion on macOS, as they seem to require ELF support.

Passing a linux triple ensures the object files are using ELF.

This fixes some GreenDragon failures.

Summary:
Currently when printing data types we include implicit scopes such as inline namespaces or anonymous namespaces.
This leads to command output like this (for `std::set<X>` with X being in an anonymous namespace):

```
(lldb) print my_set
(std::__1::set<(anonymous namespace)::X, std::__1::less<(anonymous namespace)::X>, std::__1::allocator<(anonymous namespace)::X> >) $0 = size=0 {}
```

This patch removes all the implicit scopes when printing type names in TypeSystemClang::GetDisplayTypeName
so that our output now looks like this:

```
(lldb) print my_set
(std::set<X, std::less<X>, std::allocator<X> >) $0 = size=0 {}
```

As previously GetDisplayTypeName and GetTypeName had the same output we actually often used the
two as if they are the same method (they were in fact using the same implementation), so this patch also
fixes the places where we actually want the display type name and not the actual type name.

N...

All calls to operator new in this test fail for me with:
```
expression --show-types -- *(new foo(47))`
Error output:
error: Execution was interrupted, reason: internal c++ exception breakpoint(-6)..
The process has been returned to the state before expression evaluation.
```

As calling operator new isn't the idea of this test, this patch moves that
logic to the binary with some new_* utility functions and explicitly tests
this logic in the constructor test (where we can isolate the failures and
skip them on Linux).

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

Consider large operands in G_MERGE_VALUES and G_UNMERGE_VALUES as
Ambiguous during regbank selection.
Introducing new InstType AmbiguousWithMergeOrUnmerge which will
allow us to recognize whether to narrow scalar or use s64:fprb.

This change exposed a bug when reusing data from TypeInfoForMF.
Thus when Instr is about to get destroyed (using narrow scalar)
clear its data in TypeInfoForMF. Internal data is saved based on
Instr's address, and it will no longer be valid.
Add detailed asserts for InstType and operand size.

Generate generic instructions instead of MIPS target instructions
during argument lowering and custom legalizer.
Select G_UNMERGE_VALUES and G_MERGE_VALUES when proper banks are
selected: {s32:gprb, s32:gprb, s64:fprb} for G_UNMERGE_VALUES and
{s64:fprb, s32:gprb, s32:gprb} for G_MERGE_VALUES.
Update tests. One improvement is when floating point argument in
gpr(or two gprs) gets passed to another function through gpr
unnecessary fpr-to-gpr moves are no longer generated.

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

Summary:
The check accepts now a `return (*this = something);` as return
statement too (beneath of `*this`).

Reviewers: alexfh, hokein, aaron.ballman, JonasToth

Reviewed By: aaron.ballman

Subscribers: xazax.hun, dkrupp, Szelethus, gamesh411, cfe-commits

Tags: #clang, #clang-tools-extra

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

The PluginManager contains a lot of duplicate code. I already removed a
bunch of it by introducing the templated PluginInstance class, and this
is the next step. The PluginInstances class combines the mutex and the
vector and implements the common operations.

To accommodate plugin instances with additional members it is possible
to access the underlying vector and mutex. The methods to query these
fields make use of that.

Differential revision: https://reviews.llvm.org/D74816

Summary:
Make it more convinient for the clients to select completion items by
providing a set of default characters (punctuation).

Related issue: https://github.com/clangd/clangd/issues/284

Reviewers: sammccall

Reviewed By: sammccall

Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, usaxena95, cfe-commits

Tags: #clang

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

[X86] Handle splats in LowerBUILD_VECTORvXi1 by directly emitting scalar selects instead of deferring that to LowerSELECT.

LoweSELECT will detect the constant inputs and convert to scalar
selects, but we can do it directly here.

I might remove some of the code from LowerSELECT and move it to
DAG combine so doing this explicitly will make us less dependent
on it happening in lowering.

Summary:
Depends on https://reviews.llvm.org/D71902.

The last in a series of six patches that ports the LLVM coroutines
passes to the new pass manager infrastructure.

This patch has Clang schedule the new coroutines passes when the
`-fexperimental-new-pass-manager` option is used. With this and the
previous 5 patches, Clang is capable of building and successfully
running the test suite of large coroutines projects such as
https://github.com/lewissbaker/cppcoro with
`ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER=On`.

Reviewers: GorNishanov, lewissbaker, chandlerc, junparser

Subscribers: EricWF, cfe-commits, llvm-commits

Tags: #clang

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

Summary:
Depends on https://reviews.llvm.org/D71901.

The fifth in a series of patches that ports the LLVM coroutines passes
to the new pass manager infrastructure.

The first 4 patches allow users to run coroutine passes by invoking, for
example `opt -passes=coro-early`. However, most of LLVM's tests for
coroutines use an option, `opt -enable-coroutines`, which adds all 4
coroutine passes to the appropriate legacy pass manager extension points.
This patch does the same, but using the new pass manager: when
coroutine features are enabled and the new pass manager is being used,
this adds the new-pass-manager-compliant coroutine passes to the pass
builder's pipeline.

This allows us to run all coroutine tests using the new pass manager
(besides those that use the coroutine retcon ABI used by the Swift
compiler, which is not yet supported in the new pass manager).

Reviewers: GorNishanov, lewissbaker, chandlerc, junparser, wenlei

Subscribers: wenlei, EricWF, Prazek, hiraditya, llvm-commits

Tags: #llvm

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

Summary:
Depends on https://reviews.llvm.org/D71900.

The fourth in a series of patches that ports the LLVM coroutines passes
to the new pass manager infrastructure. This patch implements
'coro-cleanup'.

No existing regression tests check the behavior of coro-cleanup on its
own, so this patch adds one. (A test named 'coro-cleanup.ll' exists, but
it relies on the entire coroutines pipeline being run. It's updated to
test the new pass manager in the 5th patch of this series.)

Reviewers: GorNishanov, lewissbaker, chandlerc, junparser, deadalnix, wenlei

Reviewed By: wenlei

Subscribers: wenlei, EricWF, hiraditya, llvm-commits

Tags: #llvm

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

This re-applies patches https://reviews.llvm.org/D71899 and
https://reviews.llvm.org/D71900, which were reverted in
https://reviews.llvm.org/rG11053a1cc61 and
https://reviews.llvm.org/rGe999aa38d16. The underlying problem that
caused two buildbots to fail with these patches is explained in
https://reviews.llvm.org/rG26f356350bd -- older compliers disagree with
the order in which the left- and right-hand side of an assignment in
LazyCallGraph ought to be evaluated, which caused an assertion in
SmallVector::operator[] to fire when the test suite was run.

Summary:
This patch teaches llvm-dwp to parse DWARFv5 info section header.
Tested this using asm test case caontaining DWARFv5 info.
Assemling it to DWO object, checking corresponding content using llvm-dwarfdump. Then finally, packaging it
to DWP using llvm-dwp and  again checking corresponding content using llvm-dwarfdump.

Reviewers: dblaikie, aprantl, probinson.

Reviewed By: dblaikie.

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

A future MC change may add a warning/error when a .section directive
specifies incorrect sh_flags/sh_type. Fix the tests to use correct
sh_flags/sh_type.

After having committed https://reviews.llvm.org/D72226, 2 buildbots
running GCC 5.4.0 began failing. The cause was the order in which those
compilers evaluated the left- and right-hand sides of the expression
`RC.SCCIndices[C] = RC.SCCIndices.size();`. This commit splits the
expression into multiple statements to avoid ambiguity, and adds a test
case that exercises the code that caused the test failures on those
older compilers (which was originally included in the reviewed patch,
https://reviews.llvm.org/D72226).

Sort forward declarations alphabetically. Also remove the two LLVM
forward declares as they frankly don't belong here.

There's no reason this should be the only one living in the
PluginManager itself.

Use YES/NO instead of OK, known issues instead of bugs and fix some
other small inconsistencies

Update the build instructions for Windows with my recent experience.

This patch changes the way we initialize and terminate the plugins in
the system initializer. It uses an approach similar to LLVM's
TARGETS_TO_BUILD with a def file that enumerates the plugins.

Previous attempts to land this failed on the Windows bot because there's
a dependency between the different process plugins. Apparently
ProcessWindowsCommon needs to be initialized after all other process
plugins but before ProcessGDBRemote.

Differential revision: https://reviews.llvm.org/D73067