This patch addresses comments in [D80203](https://reviews.llvm.org/D80203?vs=on&id=266415&whitespace=ignore-most#2062287)

Reviewed By: jhenderson

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

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

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

https://rise4fun.com/Alive/Qply8

  Pre: C2 == (-1 u>> zext(C1))
  %a = ashr %x, C1
  %s = sext %a to i16
  %r = and i16 %s, C2
    =>
  %s2 = sext %x to i16
  %r = lshr i16 %s2, zext(C1)

https://bugs.llvm.org/show_bug.cgi?id=46013

Summary:
This patch is part of a series implementing the Bfloat16 extension of the
Armv8.6-a architecture, as detailed here:

https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/arm-architecture-developments-armv8-6-a

The bfloat type, and its properties is specified in the Arm C language
extension specification:

https://developer.arm.com/docs/ihi0055/d/procedure-call-standard-for-the-arm-64-bit-architecture

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

Tags: #clang

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

The following people contributed to this patch:

- Luke Cheeseman
- Alexandros Lamprineas
- Luke Geeson
- Ties Stuij

This requires the replacement of legacy class AliasAnalysis usages with AAResults (which it typedefs to anyhow)

We already have the Instruction forward declaration.

[X86][SSE] Extend ICMP(MOVMSK(BITCAST(X))) tests to allof patterns as well as the existing noneof/anyof patterns.

As shown on PR37087, if we have a MOVMSK(BICAST(X)) from a wider vector, then by using MOVMSK from the wider type (32/64-bit elements) we can improve the chances of further combines with SimplifyDemandedBits/Elts and on some targets (skylake) can be more efficient.

This patch implements the * binary operator for values of
MatrixType. It adds support for matrix * matrix, scalar * matrix and
matrix * scalar.

For the matrix, matrix case, the number of columns of the first operand
must match the number of rows of the second. For the scalar,matrix variants,
the element type of the matrix must match the scalar type.

Reviewers: rjmccall, anemet, Bigcheese, rsmith, martong

Reviewed By: rjmccall

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

SBTarget::AddModule currently handles the UUID parameter in a very
weird way: UUIDs with more than 16 bytes are trimmed to 16 bytes. On
the other hand, shorter-than-16-bytes UUIDs are completely ignored. In
this patch, we change the parsing code to handle UUIDs of arbitrary
size.

To support arbitrary size UUIDs in SBTarget::AddModule, this patch
changes UUID::SetFromStringRef to parse UUIDs of arbitrary length. We
subtly change the semantics of SetFromStringRef - SetFromStringRef now
only succeeds if the entire input is consumed to prevent some
prefix-parsing confusion. This is up for discussion, but I believe
this is more consistent - we always return false for invalid UUIDs
rather than sometimes truncating to a valid prefix. Also, all the
call-sites except the API and interpreter seem to expect to consume
the entire input.

This also adds tests for adding existing modules 4-, 16-, and 20-byte
build-ids. Finally, we took the liberty of testing the minidump
scenario we care about - removing placeholder module from minidump and
replacing it with the real module.

Reviewed By: labath, friss

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

First step towards fixing PR37087

This patch enables yaml2elf to emit the .debug_ranges section.

Reviewed By: jhenderson

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

global-ctor.ll no longer checks what it intended to check
(@_GLOBAL__sub_I_global-ctor.ll needs a !dbg to work).
Rewrite it.

gcov 3.4 and gcov 4.2 use the same format, thus we can lower the version
requirement to 3.4

There's two properties we want to verify:

1. That the successors returned by analyzeBranch are in the CFG
   successor list, and
2. That there are no extraneous successors are in the CFG successor
   list.

The previous implementation mostly accomplished this, but in a very
convoluted manner.

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

Previously, it tried to infer the correct destination block from the
successor list, but this is a rather tricky propspect, given the
existence of successors that occur mid-block, such as invoke, and
potentially in the future, callbr/INLINEASM_BR. (INLINEASM_BR, in
particular would be problematic, because its successor blocks are not
distinct from "normal" successors, as EHPads are.)

Instead, require the caller to pass in the expected fallthrough
successor explicitly. In most callers, the correct block is
immediately clear. But, in MachineBlockPlacement, we do need to record
the original ordering, before starting to reorder blocks.

Unfortunately, the goal of decoupling the behavior of end-of-block
jumps from the successor list has not been fully accomplished in this
patch, as there is currently no other way to determine whether a block
is intended to fall-through, or end as unreachable. Further work is
needed there.

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

The 9th parameter of "static bool CC_RISCV(...)" is isFixed, not isRet.

Reviewed By: MaskRay

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

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

The KNOT pattern was missing. The others were
looking for a v1i1 -1 instead of a vector all ones.

This reverts commit 672ed538.

This commit is hitting an assertion failure across multiple bots in the test:
Profile-<arch> :: instrprof-gcov-multithread_fork.test

Failing bots include:
http://lab.llvm.org:8011/builders/llvm-avr-linux/builds/2205
http://lab.llvm.org:8011/builders/clang-cmake-aarch64-lld/builds/8967
http://lab.llvm.org:8011/builders/clang-cmake-armv7-full/builds/10789
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/27750
http://lab.llvm.org:8011/builders/sanitizer-ppc64be-linux/builds/16751

[gcov] Delete `XFAIL: host-byteorder-big-endian` for test/Transforms/GCOVProfiling/{exit-block.ll,function-numbering.ll}

recommit 11d06b95 with
fix for lit tests.

Probing of allocated stack space is now done when this option is passed. The
purpose is to protect against the stack clash attack (see
https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt).

Review: Ulrich Weigand

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

mlir-cuda-runner tests were failing post
https://reviews.llvm.org/D80676, small change to get those passing
again. More cleanup may be needed post.

The annoying behavior where the output is different due to the
legality check struck again, plus the subtarget predicate wasn't
really correctly set for DS FP atomics.

Some of the FP min/max instructions seem to be in the gfx6/gfx7
manuals, but IIRC this might have been one of the cases where the
manual got ahead of the actual hardware support, but I've left these
as-is for now since the assembler tests seem to expect them.

Move implicit include dependencies down to source files.

D80801 suggests some readability improvements before mocing this block.

MSVC doesn't care that this isn't declared for default template args but gcc (sometimes) does.

Remove unnecessary includes from CFG.cpp.

Fix implicit include dependency in X86WinEHState.cpp.

The current set is an incomprehensible mess riddled with ordering
hacks for various limitations in the legalizer at the time of writing,
many of which have been fixed. This takes a very small step in
correcting this.

The core first change is to start checking for fully legal cases
first, rather than trying to figure out all of the actions that could
need to be performed. It's recommended to check the legal cases first
for faster legality checks in the common case. This still has a table
listing some common cases, but it needs measuring whether this really
helps or not.

More significantly, stop trying to allow any arbitrary type with a
legal bitwidth as a legal memory type, and start using the bitcast
legalize action for them. Allowing loads of these weird vector types
produced new burdens we don't need for handling all of the
legalization artifacts. Unlike the SelectionDAG handling, this is
still not casting 64 or 16-bit element vectors to 32-bit
vectors. These cases should still be handled by increasing/decreasing
the number of 16-bit elements. This is primarily to fix 8-bit element
vectors.

Another change is to stop trying to handle the load-widening based on
a higher alignment. We should still do this, but the way it was
handled wasn't really correct. We really need to modify the MMO's size
at the same time, and not just increase the result type. The
LegalizerHelper does not do this, and I think this would really
require a separate WidenMemory action (or to add a memory action
payload to the LegalizeMutation). These will now fail to legalize.

The structure of the legalizer rules makes writing concise rules here
difficult. It would be easier if the same function could answer the
query the query, and report the action to perform at the same
time. Instead these two are split into distinct predicate and action
functions. This is mostly tolerable for other cases, but the
load/store rules get pretty complicated so it's difficult to keep two
versions of these functions in sync.