q[mlir][Vector] Add a ShapeCastOp(BroadcastOp) canonicalization pattern

This pattern can kick in when the source of the broadcast has a shape
that is a prefix/suffix of the result of the shape_cast.

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

[DWARFLinker] mark odr candidates inside the same object file.

This patch is extracted from D86539.

Current implementation of lookForDIEsToKeep() function skips types
duplications basing on the getCanonicalDIEOffset() data:

```
if (AttrSpec.Form != dwarf::DW_FORM_ref_addr && (UseOdr || IsModuleRef) &&
    Info.Ctxt &&
    Info.Ctxt != ReferencedCU->getInfo(Info.ParentIdx).Ctxt &&
    Info.Ctxt->getCanonicalDIEOffset() && isODRAttribute(AttrSpec.Attr))  <<<<<
  continue;
```

But that field is set after all compile units inside object file are processed:

```
for (auto &CurrentUnit : OptContext.CompileUnits)
  lookForDIEsToKeep(.., &CurrentUnit, ..);  // check CanonicalDIEOffset

DIECloner.cloneAllCompileUnits(); // set CanonicalDIEOffset
```

Thus, if the object file contains several compilation units - types would
not be deduplicated. The above solution works well for the case when the object file
contains only one compilation unit. But if the object file contains several compilation
units then types would not be deduplicated between these compilation units.

This patch changes the algorithm so that types were deduplicated between
compilation units from the same object file.

It produces binary incompatible output for the cases when several compilation units
are located inside the same object file.

Reviewed By: aprantl

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

Fix build with some GCC version: `global qualification of class name is invalid before '{' token`

[llvm-lib] Ignore /SUBSYSTEM flag

It's not clear what Microsoft's LIB.exe actually does based on the official
description of the flag (link below). We can probably ignore it for now.

https://docs.microsoft.com/en-us/cpp/build/reference/managing-a-library?view=msvc-170

Reviewed By: thieta

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

[mlir][sparse][bufferization] refine bufferization assumption enforcement

Enforce the assumption made on tensor buffers explicitly. When in-place,
reuse the buffer, but fill with all zeroes for the non-update case, since
the kernel assumes all elements are written to. When not in-place, zero
out the new buffer when materializing or when no-updates occur. Copy the
original tensor value when updates occur. This prepares migrating to the
new bufferization strategy, where these assumptions must be made explicit.

Reviewed By: springerm

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

[X86] Remove unnecessary COPY from EmitLoweredCascadedSelect.

I believe we already checked that the destination of the first
CMOV is only used by the second CMOV so I don't think there is any
reason we need the PHI to write the register that was used by the
first CMOV. We can directly use the second CMOV destination and
avoid the copy.

This may be a left over from when the cascaded select handling
was part of the main algorithm before it was refactored in D35685.

Reviewed By: pengfei

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

Allow mangled names in sanitizer clang IR gen tests.

Looks like with https://reviews.llvm.org/D127911, Windows emits more
globals with mangled names into the IR. Relax the tests in order to
allow these mangled names.

[flang] Fix couple of issue with user defined assignment in FORALL and WHERE

This patch fixes a couple of issues with the lowering of user defined assignment.

This patch is part of the upstreaming effort from fir-dev branch.

Reviewed By: klausler

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

Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>

[mlir][spirv] Support more comparisons on boolean values

Reviewed By: hanchung

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

[MLIR][Presburger] getDivRepr: fix bug where dividend was negated

Also updated the tests, which were asserting the wrong behaviour.

Reviewed By: Groverkss

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

[lldb] [test] XFAIL llgs tests failing on arm

Sponsored by: The FreeBSD Foundation

[Propeller] Encode address offsets of basic blocks relative to the end of the previous basic blocks.

This is a resurrection of D106421 with the change that it keeps backward-compatibility. This means decoding the previous version of `LLVM_BB_ADDR_MAP` will work. This is required as the profile mapping tool is not released with LLVM (AutoFDO). As suggested by @jhenderson we rename the original  section type value to `SHT_LLVM_BB_ADDR_MAP_V0` and assign a new value to the `SHT_LLVM_BB_ADDR_MAP` section type. The new encoding adds a version byte to each function entry to specify the encoding version for that function.  This patch also adds a feature byte to be used with more flexibility in the future. An use-case example for the feature field is encoding multi-section functions more concisely using a different format.

Conceptually, the new encoding emits basic block offsets and sizes as label differences between each two consecutive basic block begin and end label. When decoding, offsets must be aggregated along with basic block sizes to calculate the final offsets of basic blocks relative to the function address.

This encoding uses smaller values compared to the existing one (offsets relative to function symbol).
Smaller values tend to occupy fewer bytes in ULEB128 encoding. As a result, we get about 17% total reduction in the size of the bb-address-map section (from about 11MB to 9MB for the clang PGO binary).
The extra two bytes (version and feature fields) incur a small 3% size overhead to the `LLVM_BB_ADDR_MAP` section size.

Reviewed By: jhenderson

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

[pseudo] Grammar::parseBNF returns Grammar not unique_ptr. NFC

Update statuses and add tests for C89 DRs

This mostly finishes the DRs for C89, though there are still a few
outliers which remain. It also corrects some of the statuses of DRs
where it's not clear if it was fully resolved by the committee or not.

As a drive-by, it also adds -fsyntax-only to the tests which are
verifying diagnostic results. This was previously missed by accident.

[lldb] [test] Skip llgs tests broken due to #56268 on aarch64

Sponsored by: The FreeBSD Foundation

[MC] Allow annotating custom sections as zerofill

This is already possible for e.g. `cstring_literals`, but the entry for zerofill was unnamed.

rdar://90336380

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

[pseudo] Move cxx grammar into the cxx/ directory. NFC

[pseudo] Simplify/loosen the grammar around lambda captures.

Treat captures as a uniform list, rather than default-captures being special
snowflakes that may only appear at the start.

This accepts a larger set of (incorrect) code, and simplifies error-handling
by making this fit into the usual homogeneous-list pattern.

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

[AMDGPU] llvm.amdgcn.exp.compr is not supported on GFX11

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

[pseudo] Allow mixed designated/undesignated init lists.

This isn't allowed by the standard grammar but is allowed in C, and clang/GCC
permit it as an extension.
It avoids the need to determine which type of list we have in error-recovery.

While here, also support array index designators `{ [4]=1 }` which are
also legal in C, and common extensions in C++.

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

[AMDGPU] Use GFX11 S_PACK_HL instruction in more cases

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

[flang] Fix bugs relating to support for characters of different kinds

Fix bugs relating to support for characters of different kinds. Lowering
was creating bad FIR and MLIR that crashed in conversion to LLVM IR.

This patch is part of the upstreaming effort from fir-dev branch.

Reviewed By: jeanPerier

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

Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>

Introduce a new Dense Array attribute

This attribute is similar to DenseElementsAttr but does not support
splat. As such it has a much simpler API and does not need any smart
iterator: it exposes direct ArrayRef access.

A new syntax is introduced so that the generic printing/parsing looks
like:

  [:i64 1, -2, 3]

This attribute beings like an ArrayAttr but has a `:` token after the
opening square brace to introduce the element type (supported are I8,
I16, I32, I64, F32, F64) and the comma separated list for the data.

This is particularly convenient for attributes intended to be small,
like those referring to shapes.
For example a `transpose` operation with a `dims` attribute could be
defined as such:

  let arguments = (ins AnyTensor:$input, DenseI64ArrayAttr:$dims);
  let assemblyFormat = "$input `dims` `=` $dims attr-dict : type($input)";

And printed this way (the element type is elided in this case):

  transpose %input dims = [0, 2, 1] : tensor<2x3x4xf32>

The C++ API for dims would just directly return an ArrayRef<int64>

RFC: https://discourse.llvm.org/t/rfc-introduce-a-new-dense-array-attribute/63279

Recommit with a custom DenseArrayBaseAttrStorage class to ensure
over-alignment of the storage to the largest type.

Reviewed By: rriddle

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

[flang] Make sure that conversions are applied in FORALL degenerate contexts

For the rapid triage push, just add a TODO for the degenerate POINTER
assignment case. The LHD ought to be a variable of type !fir.box, but it
is currently returning a shadow variable for the raw data pointer. More
investigation is needed there.
Make sure that conversions are applied in FORALL degenerate contexts.

This patch is part of the upstreaming effort from fir-dev branch.

Reviewed By: jeanPerier

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

Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>

[flang] Add lowering tests

Add lowering tests left behind during the upstreaming.

This patch is part of the upstreaming effort from fir-dev branch.

Reviewed By: jeanPerier

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

Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>

[BOLT][AArch64] Handle gold linker veneers

The gold linker veneers are written between functions without symbols,
so we to handle it specially in BOLT.

Vladislav Khmelevsky,
Advanced Software Technology Lab, Huawei

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

[IRBuilder] Migrate vector operations to fold infrastructure

Migrate extractelement, insertelement and shufflevector to use the
FoldXYZ rather than CreateXYZ APIs.

This is probably NFC in practice, because the places using
InstSimplifyFolder probably aren't using vector operations.

Revert "Introduce a new Dense Array attribute"

This reverts commit 508eb41d82ca956c30950d9a16b522a29aeeb333.

UBSAN indicates some pointer mis-alignment I need to investigate

[lldb] Fix build on older Linux kernel versions

PERF_COUNT_SW_DUMMY is introduced in Linux 3.12.

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

[ArgPromotion] Unify byval promotion with non-byval

It makes sense to handle byval promotion in the same way as non-byval
but also allowing `store` instructions. However, these should
use the same checks as the `load` instructions do, i.e. be part of the
`ArgsToPromote` collection. For these instructions, the check for
interfering modifications can be disabled, though. The promotion
algorithm itself has been modified a lot: all the accesses (i.e. loads
and stores) are rewritten to the emitted `alloca` instructions. To
optimize these new `alloca`s out, the `PromoteMemToReg` function from
`Transforms/Utils/PromoteMemoryToRegister.cpp` file is invoked after
promotion.

In order to let the `PromoteMemToReg` promote as many `alloca`s as it
is possible, there should be no `GEP`s from the `alloca`s. To
eliminate the `GEP`s, its own `alloca` is generated for every argument
part because a single `alloca` for the whole argument (that
significantly simplifies the code of the pass though) unfortunately
cannot be used.

The idea comes from the following discussion:
https://reviews.llvm.org/D124514#3479676

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

Introduce a new Dense Array attribute

This attribute is similar to DenseElementsAttr but does not support
splat. As such it has a much simpler API and does not need any smart
iterator: it exposes direct ArrayRef access.

A new syntax is introduced so that the generic printing/parsing looks
like:

  [:i64 1, -2, 3]

This attribute beings like an ArrayAttr but has a `:` token after the
opening square brace to introduce the element type (supported are I8,
I16, I32, I64, F32, F64) and the comma separated list for the data.

This is particularly convenient for attributes intended to be small,
like those referring to shapes.
For example a `transpose` operation with a `dims` attribute could be
defined as such:

  let arguments = (ins AnyTensor:$input, DenseI64ArrayAttr:$dims);
  let assemblyFormat = "$input `dims` `=` $dims attr-dict : type($input)";

And printed this way (the element type is elided in this case):

  transpose %input dims = [0, 2, 1] : tensor<2x3x4xf32>

The C++ API for dims would just directly return an ArrayRef<int64>

RFC: https://discourse.llvm.org/t/rfc-introduce-a-new-dense-array-attribute/63279

Reviewed By: rriddle

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

[PowerPC] Improve getNormalLoadInput to reach more splat load
opportunities

There are straight forward splat load opportunities blocked by
getNormalLoadInput(), since those cases involve consecutive bitcasts.
Improve by looking through bitcasts.

Reviewed By: nemanjai

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

[RISCV] Implement support for the Zicbop extension

Implements the ratified RISC-V Base Cache Management Operation ISA
Extension: Zicbop, as described in
https://github.com/riscv/riscv-CMOs/blob/master/specifications/cmobase-v1.0.pdf.

This is implemented in a separate patch to Zicbom and Zicboz due to it
requiring a new ASM operand type to be defined.

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

[RISCV] Implement support for the Zicbom and Zicboz extensions

Implements the ratified RISC-V Base Cache Management Operation ISA
Extensions: Zicbom and Zicboz, as described in
https://github.com/riscv/riscv-CMOs/blob/master/specifications/cmobase-v1.0.pdf.

Zicbop is implemented in a separate patch due to it requiring a new ASM
operand type to be defined.

As discussed in the relevant issue in the upstream spec
https://github.com/riscv/riscv-CMOs/issues/47, the cbo.* instructions
use the format (rs1) or 0(rs1) for their operand, similar to the AMOs.

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

[ValueList] Include Error.h (NFC)

Hopefully fixes clang-ppc64-aix. Apparently std::function can't
be instantiated with a forward declared type in some environments.

Apply clang-tidy fixes for readability-simplify-boolean-expr in TosaToLinalg.cpp (NFC)

Apply clang-tidy fixes for readability-simplify-boolean-expr in Utils.cpp (NFC)

SelectionDAG: allow FP extensions when folding extract/insert.

Before, we were trying to sign extend half -> float, and asserted in getNode.

[PowerPC] Add base test case for load splat opportunity

Reviewed By: shchenz

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

[mlir][SCF][bufferize][NFC] Implement resolveConflicts for ParallelInsertSliceOp

This was previous implemented as part of the BufferizableOpInterface of ForEachThreadOp. Moving the implementation to ParallelInsertSliceOp to be consistent with the remaining ops and to have a nice example op that can serve as a blueprint for other ops.

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

[libc] Disable use of inlined builtins for tests

[gn build] Port 03975b7f0e5a

[libc] Fix missing static_cast

Fixed unused variable warning.

[mlir][complex] Canonicalization for consecutive complex.add and sub

Add basic canonicalization for consecutive complex.add and sub operations.

Reviewed By: pifon2a

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

[libc] Use ASSERT_ instead of EXPECT_ in memcmp tests

[VPlan] Move recipe implementations to separate file (NFC).

This patch moves the code for recipe implementations to a separate file.

The benefits are:
 * Keep VPlan.cpp smaller => faster compile-time during parallel builds.
 * Keep code for logical units together

As a follow-up I am also planning on moving all ::execute
implemetnations from LoopVectorize.cpp over to the new file, which
should help to reduce the size of the file a bit.

Reviewed By: Ayal

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

[AArch64][SME] Sink tile offset operands into the loop for load/store instructions.

This helps ISel decompose the generic offset for the tile into a base + offset.

Reviewed By: dmgreen

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

[AArch64][SME] Add SVE2 psel, uclamp, sclamp and revd IR intrinsics

When the SME feature is enabled we also gain access to a few extra
SVE2 instructions. This patch adds LLVM IR intrinsics to make use
of these new instructions:

  @llvm.aarch64.sve.psel
  @llvm.aarch64.sve.revd
  @llvm.aarch64.sve.sclamp
  @llvm.aarch64.sve.uclamp

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

[libc][mem*] Introduce Algorithms for new mem framework

This patch is a subpart of D125768 intented to make the review easier.

This patch introduces the same algorithms as in `libc/src/string/memory_utils/elements.h` but using the new API.

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

[Bitcode] Support expanding constant expressions into instructions

This implements an autoupgrade from constant expressions to
instructions, which is needed for
https://discourse.llvm.org/t/rfc-remove-most-constant-expressions/63179.

The basic approach is that constant expressions (CST_CODE_CE_*
records) now initially only create a BitcodeConstant value that
holds opcode, flags and operands IDs. Then, when the value actually
gets used, it can be converted either into a constant expression
(if that expression type is still supported) or into a sequence of
instructions. As currently all expressions are still supported,
-expand-constant-exprs is added for testing purposes, to force
expansion.

PHI nodes require special handling, because the constant expression
needs to be evaluated on the incoming edge. We do this by putting
it into a temporary block and then wiring it up appropriately
afterwards (for non-critical edges, we could also move the
instructions into the predecessor).

This also removes the need for the forward referenced constants
machinery, as the BitcodeConstants only hold value IDs. At the
point where the value is actually materialized, no forward
references are needed anymore.

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

[AArch64] Update SME load/store intrinsics to work on opaque pointers.

These intrinsics should be able to use opaque pointers, because the
load/store type is already encoded in their names and return/operand type.

Reviewed By: c-rhodes

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

[AArch64][SME] Add SME outer product intrinsics

This patch adds the following intrinsics to support the SME ACLE:

  * @llvm.aarch64.sme.mopa: Non-widening outer product + accumulate
  * @llvm.aarch64.sme.mops: Non-widening outer product + subtract
  * @llvm.aarch64.sme.mopa.wide: Widening outer product + accumulate
  * @llvm.aarch64.sme.mops.wide: Widening outer product + subtract
  * @llvm.aarch64.sme.smopa.wide: Widening signed sum of outer product + accumulate
  * @llvm.aarch64.sme.smops.wide: Widening signed sum of outer product + subtract
  * @llvm.aarch64.sme.umopa.wide: Widening unsigned sum of outer product + accumulate
  * @llvm.aarch64.sme.umops.wide: Widening unsigned sum of outer product + subtract
  * @llvm.aarch64.sme.sumopa.wide: Widening signed by unsigned sum of outer product + accumulate
  * @llvm.aarch64.sme.sumops.wide: Widening signed by unsigned sum of outer product + subtract
  * @llvm.aarch64.sme.usmopa.wide: Widening unsigned by signed sum of outer product + accumulate
  * @llvm.aarch64.sme.usmops.wide: Widening unsigned by signed sum of outer product + subtract

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

[IR] Remove support for extractvalue constant expression

This removes the extractvalue constant expression, as part of
https://discourse.llvm.org/t/rfc-remove-most-constant-expressions/63179.
extractvalue is already not supported in bitcode, so we do not need
to worry about bitcode auto-upgrade.

Uses of ConstantExpr::getExtractValue() should be replaced with
IRBuilder::CreateExtractValue() (if the fact that the result is
constant is not important) or ConstantFoldExtractValueInstruction()
(if it is). Though for this particular case, it is also possible
and usually preferable to use getAggregateElement() instead.

The C API function LLVMConstExtractValue() is removed, as the
underlying constant expression no longer exists. Instead,
LLVMBuildExtractValue() should be used (which will constant fold
or create an instruction). Depending on the use-case,
LLVMGetAggregateElement() may also be used instead.

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

[AArch64][SME] NFC: Extend tile_slice ComplexPattern to match default case.

A tile slice offset of '0' is the default and by moving this into
SelectSMETileSlice we can remove some redundant patterns.

Reviewed By: kmclaughlin

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

[RISCV] Support VECTOR_REVERSE mask operation.

Reviewed By: craig.topper

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

[Alignment] Replace commonAlignment with std::min

`commonAlignment` is a shortcut to pick the smallest of two `Align`
objects. As-is it doesn't bring much value compared to `std::min`.

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

[clang-cl] Add -emit-ast to clang-cl driver

Also make the output of -emit-ast end up where /o points.
The same with .plist files from the static analyzer.

These are changes needed to make it possible to do CTU static
analysing work with clang-cl.

Reviewed By: hans

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

[Clang] Fix: Restore warning inadvertently removed by D126061.

Before D126061, Clang would warn about this code

```
struct X {
    [[deprecated]] struct Y {};
};
```

with the warning

    attribute 'deprecated' is ignored, place it after "struct" to apply attribute to type declaration

D126061 inadvertently caused this warning to no longer be emitted. This patch
restores the previous behavior.

The reason for the bug is that after D126061, C++11 attributes applied to a
member declaration are no longer placed in `DS.getAttributes()` but are instead
tracked in a separate list (`DeclAttrs`). In the case of a free-standing
decl-specifier-seq, we would simply ignore the contents of this list. Instead,
we now pass the list on to `Sema::ParsedFreeStandingDeclSpec()` so that it can
issue the appropriate warning.

Reviewed By: aaron.ballman

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

Reland "[X86] Support `_Float16` on SSE2 and up"

Enable `COMPILER_RT_HAS_FLOAT16` to solve the lit fail.

This is split from D113107 to address #56204 and https://discourse.llvm.org/t/how-to-build-compiler-rt-for-new-x86-half-float-abi/63366

Reviewed By: zahiraam, rjmccall, bkramer

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

[CSSPGO][llvm-profgen] Reimplement SampleContextTracker using context trie

This is the followup patch to https://reviews.llvm.org/D125246 for the `SampleContextTracker` part. Before the promotion and merging of the context is based on the SampleContext(the array of frame), this causes a lot of cost to the memory. This patch detaches the tracker from using the array ref instead to use the context trie itself. This can save a lot of memory usage and benefit both the compiler's CS inliner and llvm-profgen's pre-inliner.

One structure needs to be specially treated is the `FuncToCtxtProfiles`, this is used to get all the functionSamples for one function to do the merging and promoting. Before it search each functions' context and traverse the trie to get the node of the context. Now we don't have the context inside the profile, instead we directly use an auxiliary map `ProfileToNodeMap` for profile , it initialize to create the FunctionSamples to TrieNode relations and keep updating it during promoting and merging the node.

Moreover, I was expecting the results before and after remain the same, but I found that the order of FuncToCtxtProfiles matter and affect the results. This can happen on recursive context case, but the difference should be small. Now we don't have the context, so I just used a vector for the order, the result is still deterministic.

Measured on one huge size(12GB) profile from one of our internal service. The profile similarity difference is 99.999%, and the running time is improved by 3X(debug mode) and the memory is reduced from 170GB to 90GB.

Reviewed By: hoy, wenlei

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

[CSSPGO][llvm-profgen] Reimplement computeSummaryAndThreshold using context trie

Follow-up patch to https://reviews.llvm.org/D125246, support `computeSummaryAndThreshold` based on context trie.

Reviewed By: hoy, wenlei

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

[CSSPGO][llvm-profgen] Reimplement CS profile generator using context trie

Our investigation showed ProfileMap's key is the bottleneck of the memory consumption for CS profile generation on some large services. This patch tries to optimize it by storing the CS function samples using the context trie tree structure instead of the context frame array ref. Parts of code in `ContextTrieNode` are reused.

Our experiment on one internal service showed that the context key's memory can be reduced from 80GB to 300MB.

To be compatible with non-CS profiles, the profile writer still needs to use ProfileMap as input, so rebuild the ProfileMap using the context trie in `postProcessProfiles`.

The optimization is not complete yet, next step is to reimplement Pre-inliner or profile trimmer, after that, ProfileMap should be small to be written.

Reviewed By: hoy, wenlei

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

Revert "[CoverageMapping] Remove dots from paths inside the profile"

This reverts commit d1b098fc825176242afee12b8f9dc14adf5eec51 since
it is failing on Windows builders.

[CoverageMapping] Remove dots from paths inside the profile

We already remove dots from collected paths and path mappings. This
makes it difficult to match paths inside the profile which contain
dots. For example, we would never match /path/to/../file.c because
the collected path is always be normalized to /path/file.c. This
change enables dot removal for paths inside the profile to address
the issue.

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

[mlir][Vector] Fix reordering of floating point adds during lower of `vector.contract`.

Adding the accumulator value after the `vector.contract` changes the
precision of the operation. This makes sure the accumulator is carried
through to `vector.reduce` (and down to LLVM).

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

[LoopInterchange] New cost model for loop interchange

This is another attempt to land this patch.

The patch proposed to use a new cost model for loop interchange,
which is obtained from loop cache analysis.

Given a loopnest, what loop cache analysis returns is a vector of
loops [loop0, loop1, loop2, ...] where loop0 should be replaced as
the outermost loop, loop1 should be placed one more level inside, and
loop2 one more level inside, etc. What loop cache analysis does is not
only more comprehensive than the current cost model, it is also a "one-shot"
query which means that we only need to query it once during the entire
loop interchange pass, which is better than the current cost model where
we query it every time we check whether it is profitable to interchange
two loops. Thus complexity is reduced, especially after D120386 where we
do more interchanges to get the globally optimal loop access pattern.

Updates made to test cases are mostly minor changes and some
corrections. One change that applies to all tests is that we added an option
`-cache-line-size=64` to the RUN lines. This is ensure that loop
cache analysis receives a valid number of cache line size for correct
analysis. Test coverage for loop interchange is not reduced.

Currently we did not completely remove the legacy cost model, but
keep it as fall-back in case the new cost model did not run successfully.
This is because currently we have some limitations in delinearization, which
sometimes makes loop cache analysis bail out. The longer term goal is to
enhance delinearization and eventually remove the legacy cost model
compeletely.

Reviewed By: bmahjour, #loopoptwg

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

[lldb] [test] Mark test_vCont_supports_t llgs-only

Sponsored by: The FreeBSD Foundation

[RISCV] Optimize 2x SELECT for floating-point types

Including the following opcode:
 Select_FPR16_Using_CC_GPR
 Select_FPR32_Using_CC_GPR
 Select_FPR64_Using_CC_GPR

Reviewed By: craig.topper

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

[RISCV] Fix the problem of parsing long version numbers

For example, when parsing Zbpbo0p911, an error will be reported:
"multi-character extensions must be separated by underscores"

Reviewed By: asb

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

[RISCV] Zero extend immediate for vget/vset builtins to match vector.insert/extract intrinsics.

The vector.insert/extract intrinsics require an i64 immediate argument.
This fixes a crash on RV32.

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

[LiveInterval] Simplify with partition_point. NFC

[libc++] Re-add transitive includes that had been removed since LLVM 14

This commit re-adds transitive includes that had been removed by
4cd04d1687f1, c36870c8e79c, a83f4b9cda57, 1458458b558d, 2e2f3158c604,
and 489637e66dd3. This should cover almost all the includes that had
been removed since LLVM 14 and that would contribute to breaking user
code when releasing LLVM 15.

It is possible to disable the inclusion of these headers by defining
_LIBCPP_REMOVE_TRANSITIVE_INCLUDES. The intent is that vendors will
enable that macro and start fixing downstream issues immediately. We
can then remove the macro (and the transitive includes) by default in
a future release. That way, we will break users only once by removing
transitive includes in bulk instead of doing it bit by bit a every
release, which is more disruptive for users.

Note 1: The set of headers to re-add was found by re-generating the
        transitive include test on a checkout of release/14.x, which
        provided the list of all transitive includes we used to provide.

Note 2: Several includes of <vector>, <optional>, <array> and <unordered_map>
        have been added in this commit. These transitive inclusions were
        added when we implemented boyer_moore_searcher in <functional>.

Note 3: This is a best effort patch to try and resolve downstream breakage
        caused since branching LLVM 14. I wasn't able to perfectly mirror
        transitive includes in LLVM 14 for a few headers, so I added a
        release note explaining it. To summarize, adding boyer_moore_searcher
        created a bunch of circular dependencies, so we have to break
        backwards compatibility in a few cases.

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

[RISCV] Fix misleading formatting and remove a dead getNode call. NFC

Add missing (void) for function declarations in C

llvm-reduce: Handle reducing FP values to nan

Prefer 0/1 over NaN, but it may make more sense to invert this as FP
operations with nan inputs can universally be folded into something
else.

[docs] Remove outdated status update for FreeBSD

Reviewed By: emaste, MaskRay

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

[test] Add -fsanitize=array-bounds test for pseudo flexible array member

This behavior (from commit 539e4a77bbabbc19f22b2bd24e04af2e432e599d in 2013) was untested.
The test can help detect regression introduced by 886715af962de2c92fac4bd37104450345711e4a

[lldb] Use assertState in TestIgnoredExceptions

Reland [Metadata] Add a resize capability to MDNodes and add a push_back interface to MDNode

Fixed a bug with double destruction of operands and corrected a test issue.

Note that this patch leads to a slight increase in compile time (I measured
about .3%) and a slight increase in memory usage. The increased memory usage
should be offset once resizing is used to a larger extent.

Reviewed By: dexonsmith

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

[lit][test] relaxed GTEST_TOTAL_SHARDS checking for some googletests

For machines with a small number of cores, GTEST_TOTAL_SHARDS may be
lower than 6.

Mark ASan global-location-nodebug test as unspported on win.

Windows linkers don't have the easy reachable `-Wl,-S` option to strip
the binary. Disable the test for now.

[mlir][ods] Add convertFromStorage field to parameters

This patch adds a `convertFromStorage` field to attribute or type parameters that can implement more complex logic for converting from the parameter's C++ storage type (e.g. `Optional<SmallVector<T>>`) to its C++ type (e.g. `Optional<ArrayRef<T>>`).

Reviewed By: rriddle

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

Fix-forward ASan on Windows.

D127911 deleted llvm.asan.globals. This had a side effect that we no
longer generated the `name` field for the `__asan_global` descriptor
from clang's decscription of the name, but the demangled name from the
LLVM IR. On Linux, this is the same as the clang-provided name. On
Windows, this includes the type, as the name in the IR is the mangled
name.

Attempt #1 to fix-forward the Windows bots by making the tests glob both
sides of the global name, thereby allowing types in the descriptor name.

[lld][WebAssembly] Don't apply data relocations at static constructor time

Instead, export `__wasm_apply_data_relocs` and `__wasm_call_ctors`
separately.

This is required since user code in a shared library (such as static
constructors) should not be run until relocations have been applied to
all loaded libraries.

See: https://github.com/emscripten-core/emscripten/issues/17295

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

[Clang][OpenMP] Don't overload "extension" in status doc

In Clang's OpenMPSupport.rst, "extension" is currently overloaded to
describe both:

1. Standard OpenMP features that appear only in recent versions of the
   OpenMP spec.
2. Non-standard features supported by Clang.  This usage appears in
   the final table on the page.

Last fall, we discussed this issue in the OpenMP in LLVM call and
agreed it should be corrected.  This patch takes the simple approach
of dropping the word "extension" for all occurrences of the first
usage.  The result seems to read well.

Reviewed By: ABataev

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

[libc] add printf oct conversion

The oct converter handles the %o conversion.

Reviewed By: lntue

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

[pseudo] Check follow-sets instead of tying reduce actions to lookahead tokens.

Previously, the action table stores a reduce action for each lookahead
token it should allow. These tokens are the followSet(action.rule.target).

In practice, the follow sets are large, so we spend a bunch of time binary
searching around all these essentially-duplicates to check whether our lookahead
token is there.
However the number of reduces for a given state is very small, so we're
much better off linear scanning over them and performing a fast check for each.

D128318 was an attempt at this, storing a bitmap for each reduce.
However it's even more compact just to use the follow sets directly, as
there are fewer nonterminals than (state, rule) pairs. It's also faster.

This specialized approach means unbundling Reduce from other actions in
LRTable, so it's no longer useful to support it in Action. I suspect
Action will soon go away, as we store each kind of action separately.

This improves glrParse speed by 42% (3.30 -> 4.69 MB/s).
It also reduces LR table size by 59% (343 -> 142kB).

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

Have CommandObjectParsed check for "commands that take no arguments".

This is currently being done in an ad hoc way, and so for some
commands it isn't being checked.  We have the info to make this check,
since commands are supposed to add their arguments to the m_arguments
field of the CommandObject.  This change uses that info to check whether
the command received arguments in error.

A handful of commands weren't defining their argument types, I also had
to fix them.  And a bunch of commands were checking for arguments by
hand, so I removed those checks in favor of the CommandObject one.  That
also meant I had to change some tests that were checking for the ad hoc
error outputs.

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

[asan] Add missing dependency on Demangle

Follow up to D127911.

Delete 'llvm.asan.globals' for global metadata.

Now that we have the sanitizer metadata that is actually on the global
variable, and now that we use debuginfo in order to do symbolization of
globals, we can delete the 'llvm.asan.globals' IR synthesis.

This patch deletes the 'location' part of the __asan_global that's
embedded in the binary as well, because it's unnecessary. This saves
about ~1.7% of the optimised non-debug with-asserts clang binary.

Reviewed By: vitalybuka

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

[docs] Restore missing blank line

Lost in resolving conflicts for cdfa15da94f06289dcf86173d18b6627f92ac403.

[Sanitizer][Darwin] Mark test UNSUPPORTED instead of XFAIL

This is test is failing/passing depending on the host OS version.  Need
to investigate/fix before re-enabling.

rdar://95982696

Revert "[clang] Introduce -fstrict-flex-arrays=<n> for stricter handling of flexible arrays"

This reverts D126864 and related fixes.

This reverts commit 572b08790a69f955ae0cbb1b4a7d4a215f15dad9.
This reverts commit 886715af962de2c92fac4bd37104450345711e4a.

[Sanitizer][Darwin] atos does not show line numbers for globals

atos does not show line numbers for globals and will probably not
support this anytime soon.  Mark test UNSUPPORTED instead of XFAIL.

[RISCV] Remove repeated calls to getSExtValue. NFC

[RISCV] Add tests for (load (add X, [2048,4094])). NFC

Offsets in the range [-4095,-2049] or [2048, 4094] are split into
two ADDIs. One of the ADDIs will be folded into the load/store
immediate through an post-isel peephole.

[LV] Allow scalable vectorization with vscale = 1

This change is a bit subtle. If we have a type like <vscale x 1 x i64>, the vectorizer will currently reject vectorization. The reason is that a type like <1 x i64> is likely to get simply rescalarized, and the vectorizer doesn't want to be in the game of simple unrolling.

(I've given the example in terms of 1 x types which use a single register, but the same issue exists for any N x types which use N registers. e.g. RISCV LMULs.)

This change distinguishes scalable types from fixed types under the reasoning that converting to a scalable type isn't unrolling. Because the actual vscale isn't known until runtime, using a vscale type is potentially very profitable.

This makes an important, but unchecked, assumption. Specifically, the scalable type is assumed to only be legal per the cost model if there's actually a scalable register class which is distinct from the scalar domain. This is, to my knowledge, true for all targets which return non-invalid costs for scalable vector ops today, but in theory, we could have a target decide to lower scalable to fixed length vector or even scalar registers. If that ever happens, we'd need to revisit this code.

In practice, this patch unblocks scalable vectorization for ELEN types on RISCV.

Let me sketch one alternate implementation I considered. We could have restricted this to when we know a minimum value for vscale. Specifically, for the default +v extension for RISCV, we actually know that vscale >= 2 for ELEN types. However, doing it this way means we can't generate scalable vectors when using the various embedded vector extensions which have a minimum vscale of 1.

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

Add wait for child processe(s) to exit. (amended+clang-formatted)

It was possible for the parent process to exit before the
forked child process had finished. In some shells, this
causes the pipe to close and FileCheck misses some output
from the child. Waiting for the child process to exit before
exiting the parent, assures that all output from stdout and
stderr is combined and forwarded through the pipe to FileCheck.

rdar://95241490

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

[libc++][lit][AIX] Port tests for getting time to AIX

Summary:
This patch ports libc++ LIT test cases for getting time in various locales to AIX.

Reviewed by: philnik, Mordante, libc++

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