[clangd] Move clangd tests to clangd directory. check-clangd is no longer part of check-clang-tools.

Summary:
Motivation:
 - this layout is a pain to work with
 - without a common root, it's painful to express things like "disable clangd" (D61122)
 - CMake/lit configs are a maintenance hazard, and the more the one-off hacks
   for various tools are entangled, the more we see apathy and non-ownership.

This attempts to use the bare-minimum configuration needed (while still
supporting the difficult cases: windows, standalone clang build, dynamic libs).
In particular the lit.cfg.py and lit.site.cfg.py.in are merged into lit.cfg.in.
The logic in these files is now minimal.

(Much of clang-tools-extra's lit configs can probably be cleaned up by reusing
lit.llvm.llvm_config.use_clang(), and every llvm project does its own version of
LDPATH mangling. I haven't attempted to fix any of those).

Docs are still in clang-tools-extra/docs, I don't have any plans to touch those.

Reviewers: gribozavr

Subscribers: mgor...

The latter doesn't seem to be working for all targets. This addresses
the issue introduced in r359413.

llvm-svn: 359423

llvm-svn: 359422

This was introduced in r359413.

llvm-svn: 359421

Summary:
Dump more information about "access violation" and "in page error" exceptions to
description. Description now contains data about read/write violation type and
actual address as described at
https://docs.microsoft.com/en-us/windows/desktop/api/winnt/ns-winnt-_exception_record

Reviewers: asmith, stella.stamenova

Reviewed By: stella.stamenova

Subscribers: teemperor, amccarth, abidh, lldb-commits, aleksandr.urakov

Tags: #lldb

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

llvm-svn: 359420

This was introduced in r359413.

llvm-svn: 359419

[X86] Remove some intel syntax aliases on (v)cvtpd2(u)dq, (v)cvtpd2ps, (v)cvt(u)qq2ps. Add 'x' and'y' suffix aliases to masked version of the same in att syntax.

The 128/256 bit version of these instructions require an 'x' or 'y' suffix to
disambiguate the memory form in att syntax.

We were allowing the same suffix in intel syntax, but it appears gas does not
do that.

gas does allow the 'x' and 'y' suffix on register and broadcast forms even
though its not needed. We were allowing it on unmasked register form, but not on
masked versions or on masked or unmasked broadcast form.

While there fix some test coverage holes so they can be extended with the 'x'
and 'y' suffix tests.

llvm-svn: 359418

llvm-svn: 359417

* char SymbolAddrStr[18] can't hold "%" PRIo64 which may need 22 characters.
* Use range-based for
* Delete unnecessary typedef
* format(...).print(Str, sizeof(Str)) + outs() << Str => outs() << format(...)
* Use cascading outs() << .. << ..
* Use iterator_range(Container &&c)
* (A & B) == B => A & B   if B is a power of 2
* replace null sentinel in constants with makeArrayRef

llvm-svn: 359416

llvm-svn: 359415

llvm-svn: 359414

Symbol aliases are supported by all platforms that compiler-rt builtins
target, and we can use these instead of function redirects to avoid the
extra indirection.

This is part of the cleanup proposed in "[RFC] compiler-rt builtins
cleanup and refactoring".

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

llvm-svn: 359413

llvm-svn: 359412

Use the uniform single line C++/99 style for code comments.

This is part of the cleanup proposed in "[RFC] compiler-rt builtins
cleanup and refactoring".

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

llvm-svn: 359411

Update formatting to use the LLVM style.

This is part of the cleanup proposed in "[RFC] compiler-rt builtins
cleanup and refactoring".

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

llvm-svn: 359410

llvm-svn: 359409

llvm-svn: 359408

llvm-svn: 359407

[X86][SSE] combineExtractVectorElt - add early-out to return zero/undef for out-of-range extraction indices.

llvm-svn: 359406

llvm-svn: 359405

llvm-svn: 359404

llvm-svn: 359403

I got confused on the terminology, and the change in D60598 was not
correct. I was thinking of "exact" in terms of the result being
non-approximate. However, the relevant distinction here is whether
the result is

 * Largest range such that:
   Forall Y in Other: Forall X in Result: X BinOp Y does not wrap.
   (makeGuaranteedNoWrapRegion)
 * Smallest range such that:
   Forall Y in Other: Forall X not in Result: X BinOp Y wraps.
   (A hypothetical makeAllowedNoWrapRegion)
 * Both. (makeExactNoWrapRegion)

I'm adding a separate makeExactNoWrapRegion method accepting a
single APInt (same as makeExactICmpRegion) and using it in the
places where the guarantee is relevant.

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

llvm-svn: 359402

llvm-svn: 359401

Some of the combines might be further improved if we lower more shuffles with X86ISD::VPERMV3 directly, instead of waiting to combine the results.

llvm-svn: 359400

The x86 test diffs don't look great because of extra move ops,
but FP min/max should clearly be included in the list.

llvm-svn: 359399

This was originally part of D61028, but it's an independent diff.

If we try the repeated divisor reciprocal transform before producing an estimate sequence,
then we have an opportunity to use scalar fdiv. On x86, the trade-off is 1 divss vs. 5
vector FP ops in the default estimate sequence. On recent chips (Skylake, Ryzen), the
full-precision division is only 3 cycle throughput, so that's probably the better perf
default option and avoids problems from x86's inaccurate estimates.

The last 2 tests show that users still have the option to override the defaults by using
the function attributes for reciprocal estimates, but those patterns are potentially made
faster by converting the vector ops (including ymm ops) to scalar math.

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

llvm-svn: 359398

llvm-svn: 359397

An xor reduction of a bool vector can be optimized to a parity check of the MOVMSK/BITCAST'd integer - if the population count is odd return 1, else return 0.

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

llvm-svn: 359396

llvm-svn: 359395

On a Darwin host we were modifying the `FUZZER_SUPPORTED_ARCH` in place
which would strip out non-x86 architectures. This unhelpful if we
want to use `FUZZER_SUPPORTED_ARCH` later.

To fix this we introduce `FUZZER_TEST_ARCH` which is similar to what we
have for for the other sanitizers. For non-Darwin host platforms
`FUZZER_TEST_ARCH` is the same as `FUZZER_SUPPORTED_ARCH` but for Darwin
host platforms we use `darwin_filter_host_archs(...)` as the previous
code did.

llvm-svn: 359394

Add the rest of test cases covering functions defined in mmintrin.h on PowerPC.

Reviewed By: Jinsong Ji

llvm-svn: 359393

[X86] Remove (V)MOV64toSDrr/m and (V)MOVDI2SSrr/m. Use 128-bit result MOVD/MOVQ and COPY_TO_REGCLASS instead

Summary:
The register form of these instructions are CodeGenOnly instructions that cover
GR32->FR32 and GR64->FR64 bitcasts. There is a similar set of instructions for
the opposite bitcast. Due to the patterns using bitcasts these instructions get
marked as "bitcast" machine instructions as well. The peephole pass is able to
look through these as well as other copies to try to avoid register bank copies.

Because FR32/FR64/VR128 are all coalescable to each other we can end up in a
situation where a GR32->FR32->VR128->FR64->GR64 sequence can be reduced to
GR32->GR64 which the copyPhysReg code can't handle.

To prevent this, this patch removes one set of the 'bitcast' instructions. So
now we can only go GR32->VR128->FR32 or GR64->VR128->FR64. The instruction that
converts from GR32/GR64->VR128 has no special significance to the peephole pass
and won't be looked through.

I guess the other option would be to add support to copyPhysReg to just promote
the GR32->GR64 to a GR64->GR64 copy. The upper bits were basically undefined
anyway. But removing the CodeGenOnly instruction in favor of one that won't be
optimized seemed safer.

I deleted the peephole test because it couldn't be made to work with the bitcast
instructions removed.

The load version of the instructions were unnecessary as the pattern that selects
them contains a bitcasted load which should never happen.

Fixes PR41619.

Reviewers: RKSimon, spatel

Reviewed By: RKSimon

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 359392

Minor generalization of the existing <32 x i1> pre-AVX2 split code.
........
Causing irregular buildbot failures.

llvm-svn: 359391

llvm-svn: 359390

Minor generalization of the existing <32 x i1> pre-AVX2 split code.

llvm-svn: 359389

sort order by types and add vXi32/vXi16/vXi8 test coverage

llvm-svn: 359388

Summary:
As reported in LLVM bug 41487, the check in this function is wrong and should be
the same as the described check in the comment (which is correctly copied from the
ARM ISA reference).

Reviewers: #lldb, davide, JDevlieghere

Reviewed By: #lldb, davide, JDevlieghere

Subscribers: davide, javed.absar, kristof.beyls, lldb-commits

Tags: #lldb

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

llvm-svn: 359387

As predicate masks are legal on AVX512 targets, we avoid MOVMSK in these cases, but we can just bitcast the bool vector to the integer equivalent directly - avoiding expansion of the reduction to a shuffle pattern.

llvm-svn: 359386

AND/OR/XOR tests for the @llvm.experimental.vector.reduce intrinsics

AND/OR are pretty good (pre-AVX512), XOR (not so common but used for parity reduction) is still pretty bad.

llvm-svn: 359385