As discussed on D78935

of a struct that cover the whole struct

This can happen when the rest of the
members of are zero length. Following
the same pattern applied to the SROA
pass in:
d7f6f163

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

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

Summary: FP reductions no longer use these intrinsics since D78723.

Reviewers: efriedma, sdesmalen

Reviewed By: efriedma, sdesmalen

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

Summary:
This patch implements custom floating-point reduction ISD nodes that
have vector results, which are used to lower the following intrinsics:

    * llvm.aarch64.sve.fadda
    * llvm.aarch64.sve.faddv
    * llvm.aarch64.sve.fmaxv
    * llvm.aarch64.sve.fmaxnmv
    * llvm.aarch64.sve.fminv
    * llvm.aarch64.sve.fminnmv

SVE reduction instructions keep their result within a vector register,
with all other bits set to zero.

Changes in this patch were implemented by Paul Walker and Sander de
Smalen.

Reviewers: sdesmalen, efriedma, rengolin

Reviewed By: efriedma

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

Summary:
This patch tries to ensure that we do something sensible when
generating code for the ISD::INSERT_VECTOR_ELT DAG node when operating
on scalable vectors. Previously we always returned 'undef' when
inserting an element into an out-of-bounds lane index, whereas now
we only do this for fixed length vectors. For scalable vectors it
is assumed that the backend will do the right thing in the same way
that we have to deal with variable lane indices.

In this patch I have permitted a few basic combinations for scalable
vector types where it makes sense, but in general avoided most cases
for now as they currently require the use of BUILD_VECTOR nodes.

This patch includes tests for all scalable vector types when inserting
into lane 0, but I've only included one or two vector types for other
cases such as variable lane inserts.

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

Summary: The condition added with the new setting checked whether the character was an l-brace, not specifically a lambda l-brace, when deciding whether it was possible to break before it or not. This caused the l-brace of some initialiser lists to break onto the next line with the first argument of the initialiser list when the setting was enabled.

Reviewed By: MyDeveloperDay, Wawha

Patch By: duncan-llvm

Subscribers: cfe-commits

Tags: #clang, #clang-format

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

Summary:
Due to the order in which the enum cases were defined the old options which were retained for backwards compatibility were being preferred over the new options when printing with the --dump-config option.

Reviewers: MyDeveloperDay

Reviewed By: MyDeveloperDay

Patch By:  duncan-llvm

Subscribers: cfe-commits

Tags: #clang, #clang-format

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

Summary:
BTW my actual code that hit this issue is like

```
[a, b = std::move(b)](auto &&... c) mutable -> std::invoke_result_t<decltype(b), decltype(c)...> { /* omitted */ }
```

where this explicit return type is required for SFINAE.

Reviewed By: krasimir, MyDeveloperDay

Patch By: johnchen902

Subscribers: krasimir, dexonsmith, cfe-commits

Tags: #clang-format, #clang

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

Summary:
This is a tentative fix for https://bugs.llvm.org/show_bug.cgi?id=45357

Spaces seem to be introduced between * and * due to changes brought in for {D69573}

Reviewers: sylvestre.ledru, mitchell-stellar, sammccall, Abpostelnicu, krasimir, jbcoe

Reviewed By: Abpostelnicu

Subscribers: tstellar, hans, Abpostelnicu, cfe-commits

Tags: #clang, #clang-format

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

[clang-format] NFC Correct clang-format headers file so documentation can be once again autogenerated

Summary:
`ClangFormatStyleOptions.rst` should ALWAYS be autogenerated from Format.h using `clang/docs/tools/dump_format_style.py` if not its liable to get removed leaving options undocumented.

This revision reworks the documentation for {D73354} {D73768} to ensure we can continue to regenerated

Fix other minor changes that ensure the documentation remains consistent (Format.h obviously got re clang-formatted after the rst had been regenerated previously)

Reviewed By: krasimir

Subscribers: cfe-commits

Tags: #clang, #clang-format

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

This makes it consistent throughout the options, although the end result
is unchanged.

Summary:
The purpose of this is to aid in having code behave differently on
Operations based on their Dialect without caring about the specific
Op. Additionally this is consistent with most other types supporting
isa<> and dyn_cast<>.

A Dialect matches isa<> based only on its namespace and relies on each
namespace being unique.

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

Summary: There is no need to create BPI explicitly. It should be requested through AM in a normal way.

Reviewers: skatkov

Reviewed By: skatkov

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

Summary:
Change std::vector to SmallVector to prevent re-allocations and to
have small pre-allocated storage.

Reviewers: clayborg, dblaikie

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

The loops over use operands and def operands were mostly identical.
Combine them, and likewise for load memoperands and store memoperands.
NFC.

It's cleaner to check this in the callers instead.

Summary:
This makes FileShardedIndex more robust and gets rid of the need for a
URIToFileCache, as it is done by the callers now and it is only once per file,
rather than once per symbol.

Reviewers: sammccall

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

Tags: #clang

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

The generic implementation is actually specific to x86. It assumes the
offset is relative to the end of the instruction and the immediate is
not scaled (which is false on most RISC).

Summary:
By design 'BranchProbabilityInfo:: getEdgeProbability(const BasicBlock *Src, const BasicBlock *Dst) const' should return sum of probabilities over all edges from Src to Dst. Current implementation is buggy and returns 1/num_of_successors if probabilities are not explicitly set.

Note current implementation of BPI printing has an issue as well and annotates each edge with sum of probabilities over all ages from one basic block to another. That's why 30% probability reported (instead of 10%) in the lit test. This is not urgent issue since only printing is affected.
Note also current implementation assumes that either all or none edges have probabilities set. This is not the only place which uses such assumption. At least we should assert that in verifier. In addition we can think on a more robust API of BPI which would prevent situations.

Reviewers: skatkov, yrouban, taewookoh

Reviewed By: skatkov

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

Summary: Currenlty BPI unconditionally creates post dominator tree each time. While this is not incorrect we can save compile time by reusing existing post dominator tree (when it's valid) provided by analysis manager.

Reviewers: skatkov, taewookoh, yrouban

Reviewed By: skatkov

Subscribers: hiraditya, steven_wu, dexonsmith, llvm-commits

Tags: #llvm

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

The lnt test suite defines custom result codes [1].  Support those via
an extension API instead of "by accident", which should offer the
advantage of properly handling them when we print test results.

[1] https://reviews.llvm.org/D77986

Reviewed By: Meinersbur

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

Reviewers: rnk

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

This revision allows masked vector transfers with m-D buffers and n-D vectors to
progressively lower to m-D buffer and 1-D vector transfers.

For a vector.transfer_read, assuming a `memref<(leading_dims) x (major_dims) x (minor_dims) x type>` and a `vector<(minor_dims) x type>` are involved in the transfer, this generates pseudo-IR resembling:
```
     if (any_of(%ivs_major + %offsets, <, major_dims)) {
       %v = vector_transfer_read(
         {%offsets_leading, %ivs_major + %offsets_major, %offsets_minor},
          %ivs_minor):
         memref<(leading_dims) x (major_dims) x (minor_dims) x type>,
         vector<(minor_dims) x type>;
     } else {
       %v = splat(vector<(minor_dims) x type>, %fill)
     }
```

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

gold has an option --print-symbol-counts= which prints:

  // For each archive
  archive $archive $members $fetched_members
  // For each object file
  symbols $object $defined_symbols $used_defined_symbols

In most cases, `$defined_symbols = $used_defined_symbols` unless weak
symbols are present. Strangely `$used_defined_symbols` includes symbols defined relative to --gc-sections discarded sections.
The `symbols` lines do not appear to be useful.

`archive` lines are useful: `$fetched_members=0` lines correspond to
unused archives. The information can be used to trim dependencies.

This patch implements --print-archive-stats= which prints the number of
members and the number of fetched members for each archive.

Reviewed By: grimar

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

This option can cancel --no-rosegment and it just seems right to have
a corresponding positive option for a --no-* negative option.

Anecdotally, gold had --rosegment but did not have --no-rosegment.
I added --no-rosegment (https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=9a6c68caa9543e09b064b7ac7c2b658f277bc19c) for binutils>=2.35

Summary:
If this is called before the malloc call in a thread (or in the whole
program), the lazy initialization of the allocation can overwrite
Options.

Reviewers: pcc, cryptoad

Subscribers: #sanitizers, llvm-commits

Tags: #sanitizers

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

This range allows for performing many different operations on successor operands, including erasing/adding/setting. This removes the need for the explicit canEraseSuccessorOperand and eraseSuccessorOperand methods.

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

[mlir][DeclareOpInterfaceMethods] Allow specifying a set of methods to force declaration generation for.

Currently a declaration won't be generated if the method has a default implementation. Meaning that operations that wan't to override the default have to explicitly declare the method in the extraClassDeclarations. This revision adds an optional list parameter to DeclareOpInterfaceMethods to allow for specifying a set of methods that should always have the declarations generated, even if there is a default.

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

This provides a general hash and comparison for checking if two operations are equivalent. This revision also optimizes the handling of result types to take advantage of how result types are stored on the operation.

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

This class allows for mutating an operand range in-place, and provides vector like API for adding/erasing/setting. ODS now uses this class to generate mutable wrappers for named operands, with the name `MutableOperandRange <operand-name>Mutable()`

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

This new test checks some of the debug output to ensure what iteration
the outliner reached a fixed point. For now I am making it REQUIRES:
asserts so that it wont break any bots that have asserts disabled.

Relatively straightforward diff, to set the stage for calling functions
in dylibs.

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