parseNormalizedArchString adds a code path that creates a RISCVISAInfo
including extensions that may not be supported by LLVM (rather than
erroring or just ignoring them). Therefore, toFeatureVector needs to
check the extension is supported in order to avoid creating unrecognised
feature strings.

This change shouldn't impact any code paths used outside of test code,
but this will be relied upon by the next patch which moves llvm-objdump
and related tools over to using parseNormalizedArchString.

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

Make sure unresolved headers are not analyzed as part of unused
includes.

Also introduces a testing fixture for analyze tests

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

Similar to D142687

Reviewed By: nikic

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

This demonstrates really bad rematerialization support
for 64-bit constants which need to be split into 32-bit pieces.

Fixes regressions from patch to turn more classes into fcmp.

To this moment this check were ignoring only inline
union special members, From now also out-of-line
special members going to be ignored. Also extended
support for IgnoreMacros to cover also macros used
inside a body, or used preprocesor directives.

Fixes:
 - https://github.com/llvm/llvm-project/issues/28300
 - https://github.com/llvm/llvm-project/issues/40554

Reviewed By: alexander-shaposhnikov

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

Check flags always enabled or disabled code blocks in preprocessor '#if'
conditions, such as '#if 0' and '#if 1' etc.

Reviewed By: carlosgalvezp

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

Since D137859, these have not been used.

Reviewed By: Renaud-K

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

This logic was added in https://reviews.llvm.org/D95943 specifically to
handle an issue for non-prevailing global variables. It turns out that
it adds a new issue for prevailing glboal variables, since those could
be replaced by an available_externally definition and hence incorrectly
omitted from the output object file. Limit the import to non-prevailing
global variables to fix this, as suggested by @tejohnson.

The bulk of the diff is mechanical changes to thread isPrevailing
through to where it's needed and ensure it's available before the
relevant calls; the actual logic change itself is straightforward.

Fixes https://github.com/llvm/llvm-project/issues/61677

Reviewed By: tejohnson

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

This reverts commit 86dbcafd.

Reverting since this depends on db288184
which broke our lto builders reported by fxbug.dev/12380.

This reverts commit db288184.

Reverting since it broke our lto builders reported by fxbug.dev/123807.

clang-format already has logic to threat the right-hand side of an
equals sign. This patch applies that logic to template defaults,
which are likely to be non-template type parameters in which case the
default value should be annotated as an expression.
This should mostly only ever apply to bool and &&.

Fixes https://github.com/llvm/llvm-project/issues/61664

Reviewed By: MyDeveloperDay, owenpan

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

When using BraceWrapping.AfterClass or BraceWrapping.AfterStruct, the
token annotator relies on the first token of the line to determine if
we're dealing with a struct or class, however, this check is faulty if
it's actually a function with an elaborated struct/class return type, as
is common in C.

This patch skips the check if the brace is already annotated as
FunctionLBrace, in which case we already know it's a function and should
be treated as such.

Fixes https://github.com/llvm/llvm-project/issues/58527

Reviewed By: HazardyKnusperkeks, owenpan

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

The C++ grammar allows lambdas to have a *requires-clause* in two
places, either directly after the *template-parameter-list*, such as:

`[] <typename T> requires foo<T> (T t) { ... };`

Or, at the end of the *lambda-declarator* (before the lambda's body):

`[] <typename T> (T t) requires foo<T> { ... };`

Previously, these cases weren't handled at all, resulting in weird
results.

Note that this commit only handles token annotation, so the actual
formatting still ends up suboptimal. This is mostly because I do not yet
know how to approach making the requires clause formatting of lambdas
match the formatting for functions.

Fixes https://github.com/llvm/llvm-project/issues/61269

Reviewed By: HazardyKnusperkeks, owenpan

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

DmaOp will read the source buffer and write the destination buffer so need to add some traits for it.

Reviewed By: bondhugula

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

Instead of calling isCopyInstr again, just pass the DestSourcePair
from the isCopyInstr call from the caller.

See D146517.

A cast is necessary to avoid implicit narrowing warnings
when those are enabled.

Reviewed By: abrachet

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

The sibling fusion profitability checks shouldn't rely on the presence
of a store op in the sibling. The reuse is between the loads.

Fixes issues raised at https://discourse.llvm.org/t/understanding-the-affine-loop-fusion-pass/69452

Reviewed By: dcaballe

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

Extra tests:
* result is used by instruction
* constant vector operands
* multiply fed by other math instructions
* extra test with larger stride

To avoid the individual files getting too big with further additions.

Reviewed By: MyDeveloperDay

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

before:
```
(opcode *>o1) = 6.1;
a inside{b, c};
x = { >> {j}};
```

after:
```
(opcode *> o1) = 6.1;
a inside {b, c};
x = {>>{j}};
```

Reviewed By: MyDeveloperDay

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

Meanwhile, use UniformityAnalysis instead of LegacyDivergenceAnalysis to collect divergence info.

Reviewed By: arsenm, sameerds

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

While it's apparently valid to place Bash redirections anywhere in a
command-line, it is by far most frequently placed last. This changes
a few tests that did not conform to this convention and which I
originally thought were wrong.

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

Those seem to have been failing for a while but we might not have noticed
because of the recent CI instability issues. I'm marking them as unsupported
to try to get the CI functional again, especially since the majority of
<format> tests are already not working on GCC 12.

Move the real LLVM_LIBC_FUNCTION macro definitions to
LLVM_LIBC_FUNCTION_IMPL and make LLVM_LIBC_FUNCTION a wrapper to
expand macros in its arguments.  This makes it possible to
compile libc implementation and test files with -Dfunc=othername.

Reviewed By: sivachandra

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

Currently the filetype flag is not documented, and knowing the behavior
of this flag is fairly important for doing anything other than
disassembling to text assembly.

Reviewed By: lattner

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

Including system headers in a namespace is not safe.

LLVM implements the 0.3 draft specification:
https://github.com/riscv/riscv-crypto/releases/download/v20230206/riscv-crypto-spec-vector.pdf
, and current vector crypto extension version can be found in:
https://github.com/riscv/riscv-crypto.

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

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

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

The bug is introduced in rGe4ceb5a7 which set the wrong offset from
the stack base. This patch is to fix the bug.

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

These files are not used because the generic sqrt and sqrtf
functions already go through internal layers that reach the
machine-specific internal implemenations.

Reviewed By: sivachandra

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