ArmSME is also 'Scalable' but since these tests are predicated on
different configuration flags they can't live in the same directory, so
it makes sense to rename this directory to ArmSVE. This is also
consistent with Vector CPU integration tests.

Reviewed By: awarzynski

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

We no longer allow calls to functions with the `amdgpu_gfx` calling
convention from functions with the `amdgpu_cs_chain_preserve` calling
convention. See D153517.

Also mention that we can't have a chain call from
amdgpu_cs_chain_preserve using more VGPRs than it has received.

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

This reverts commit 16ccba51.

This is failing across Linaro's bots e.g.:
https://lab.llvm.org/buildbot/#/builders/188/builds/34393

This is primarily to avoid trailing unit dims:
```
%1 = vector.create_mask %c1, %dim_0, %c1, %c1 : vector<1x4x1x1xi1>
%2 = vector.shape_cast %1 : vector<1x4x1x1xi1> to vector<1x4xi1>
```
becomes:
```
%1 = vector.create_mask %c1, %dim_0 : vector<1x4xi1>
```

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

Calls to member operators are a special case in that their callees have pointer
type. The callees of non-operator non-static member functions are not pointers.
See the comments in the code for details.

This issue came up in the Crubit nullability check; the fact that we weren't
modeling the `PointerValue` caused non-convergence.

Reviewed By: ymandel, xazax.hun

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

I had to tighten the restrictions on PatFrags a bit to make it consistent: instructions that
define the root of a PF can only have one def.

Reviewed By: arsenm

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

Minix is a ToolChain that was added back in 2010 but has been
unmaintained with no test. The constructed command line contains
/usr/gnu/include/c++/4.4.3 and CompilerRT-Generic which are unlikely
working for a long time.

Contiki is a barebone ToolChain that just enables safestack.
This doesn't justify a new ToolChain.

Remove these ToolChains so that their target triples will use Generic_ELF instead.

If these developers feel like having an updated llvm-project is useful,
fixing other build issues and adding a new ToolChain is much better than
having the unmaintained ToolChains.

Reviewed By: brad

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

Apple needs __need_ macros for rsize_t and offsetof. Add those, and also ones for nullptr_t, unreachable, max_align_t.

Reviewed By: aaron.ballman, efriedma, #libc, ldionne

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

Apple needs a `__need_` macro for va_list. Add one, and also ones for va_start/va_arg/va_end, __va_copy, va_copy.

Reviewed By: aaron.ballman

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

Fixes compilation issues when the generated code does not live in the `mlir` namespace.

Reviewed By: mehdi_amini

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

Fixes #64895.

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

... instead of UNSUPPORTED.

This is a GSoC 2023 project ([discourse link](https://discourse.llvm.org/t/coverage-support-a-hierarchical-directory-structure-in-generated-coverage-html-reports/68239)).

llvm-cov currently generates a single top-level index HTML file, which causes rendering scalability issues in large projects. This patch adds support for hierarchical directory structure into the HTML reports to solve scalability issues by introducing the following changes:

- Added a new command line option `--show-directory-coverage` for `llvm-cov show`. It works both for `--format=html` and `--format=text`.
- Two new classes: `CoveragePrinterHTMLDirectory` and `CoveragePrinterTextDirectory` was added to support the new option.
- A tool class `DirectoryCoverageReport` was added to support the two classes above.
- Updated the document.
- Added a new regression test for `--show-directory-coverage`.

Reviewed By: phosek, gulfem

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

GCC 12 (https://gcc.gnu.org/PR101696) allows `arch=x86-64`
`arch=x86-64-v2` `arch=x86-64-v3` `arch=x86-64-v4` in the
target_clones function attribute. This patch ports the feature.

* Set KeyFeature to `x86-64{,-v2,-v3,-v4}` in `Processors[]`, to be used
  by X86TargetInfo::multiVersionSortPriority
* builtins: change `__cpu_features2` to an array like libgcc. Define
  `FEATURE_X86_64_{BASELINE,V2,V3,V4}` and depended ISA feature bits.
* CGBuiltin.cpp: update EmitX86CpuSupports to handle `arch=x86-64*`.

Close https://github.com/llvm/llvm-project/issues/55830

Reviewed By: pengfei

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

Similar to SelectionDAG, this patch treats HwMode as an additional
predicate that needs to be satisfied for GIM_CheckFeatures.

The existing predicate passes around Record * that point to predicate
records. While HwMode expansion creates a string that needs to be
checked.

Each HwMode predicate string is uniqued by a new map that assigns
it an index. Each Rule stores the index, or -1 if HwMode doesn't
apply.

The HwMode indices each create a new Predicate feature bit and the
check string from the HwMode is used to set the feature bit.
GIM_CheckFeatures is emitted when the rule has Predicates or the HwModeIdx
is not -1.

Reviewed By: arsenm

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

Use the templated Bitset added in D158576.

Reviewed By: arsenm

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

[DAGCombiner][RISCV][AArch64][PowerPC] Restrict foldAndOrOfSETCC from using SMIN/SMAX where and OR/AND would do.

This removes some diffs created by D153502.

I'm assuming an AND/OR won't be worse than an SMIN/SMAX. For
RISC-V at least, AND/OR can be a shorter encoding than SMIN/SMAX.

It's weird that we have two different functions responsible for
folding logic of setccs, but I'm not ready to try to untangle that.

I'm unclear if the PowerPC chang is a regression or not. It looks
like it might use more registers, but I don't understand PowerPC
register so I'm not sure.

Reviewed By: arsenm

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

Now strings that are too long for one line in C#, Java, JavaScript, and
Verilog get broken into several lines.  C# and JavaScript interpolated
strings are not broken.

A new subclass BreakableStringLiteralUsingOperators is used to handle
the logic for adding plus signs and commas.  The updateAfterBroken
method was added because now parentheses or braces may be required after
the parentheses or commas are added.  In order to decide whether the
added plus sign should be unindented in the BreakableToken object, the
logic for it is taken out into a separate function
shouldUnindentNextOperator.

The logic for finding the continuation indentation when the option
AlignAfterOpenBracket is set to DontAlign is not implemented yet.  So in
that case the new line may have the wrong indentation, and the parts may
have the wrong length if the string needs to be broken more than once
because finding where to break the string depends on where the string
starts.

The preambles for the C# and Java unit tests are changed to the newer
style in order to allow the 3-argument verifyFormat macro.  Some cases
are changed from verifyFormat to verifyImcompleteFormat because those
use incomplete code and the new verifyFormat function checks that the
code is complete.

The line in the doc was changed to being indented by 4 spaces, that is,
the default continuation indentation.  It has always been the case.  It
was probably a mistake that the doc showed 2 spaces previously.

Reviewed By: MyDeveloperDay

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

I decided not to wait for D149088 because it was taking a long time.

The capture group in the regexp was changed to non-capturing.  It
doesn't need to be captured.

Reviewed By: HazardyKnusperkeks, owenpan

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

There is a note in coroutines.rst to say the coroutine intrinsics are
WIP. This is not close to the status quo. The status of LLVM coroutines
have been into maintaining stage. So it looks better to remove the WIP
note in the document. The warning to compatibility remains there.

The fix we sent for https://github.com/llvm/llvm-project/issues/56301
may bring performance regressions. But we didn't mention it in the
ReleaseNotes so that users may get confused. e.g,
https://github.com/llvm/llvm-project/issues/64933. So this patch
mentions the possible side effect and the potential solutions in
https://github.com/llvm/llvm-project/issues/64945 to avoid
misunderstandings.

We made some changes to the libc++ CI pipeline that take for granted
that we're running on libc++'s own Docker images. This was necessary for
a temporary period until widely-used tools update to a version that can
handle C++20 modules.

However, this had the unintended consequence of breaking the Clang CI
pipeline, which used the libc++ CI scripts as an implementation detail.
Instead, decouple the Clang CI pipeline from the libc++ build scripts.

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

This is obviously a hack, but it's too late at night to figure out the
exact issue and which commit introduced it, and I want to get the CI
back to green for contributors overnight.

According to https://www.ibm.com/docs/en/xl-c-and-cpp-linux/16.1.1?topic=functions-vec-promote, elements not specified by the input index argument are undefined. So that we don't need to set these elements to be zeros.

Reviewed By: nemanjai, #powerpc

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

GCC<6.2 has been unsupported since April 2022 (commit 4c72deb6).

X86TargetParser.cpp has another workaround that the other 2 nearly identical places don't have. Remove them as well.

Reviewed By: arsenm, craig.topper

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

Pointer comparison is not reliable in this case. Use ASTStructuralEquivalence
to compute FriendCountAndPosition.

Reviewed By: balazske

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

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

Select fmul x, -K -> ldexp(-x, log2(fabsK))
Select fmul fabs(x), -K -> ldexp(-|x|, log2(fabsK))

https://reviews.llvm.org/D158173

There's nothing special about f16 sqrt handling.

https://reviews.llvm.org/D158090