These limitations are too strict, and their only purpose is to avoid code
size explosion. These restrictions seem obsolete, and the size problem
is solved in other places through cheap expansion limits.

The motivation is that the old code cannot deal with comparisons against
induction variant's increment.

Differential Revision: https://reviews.llvm.org/D138412
Reviewed By: lebedev.ri, reames

`-fapprox-func` should be disabled by `-fp-model={strict|precise}`,
as well as other fast-math flags. See the last changes in
`clang/test/Driver/fp-model.c`.

Probably this route (`case options::OPT_ffp_model_EQ`) was forgot
to update in D106191 and D114564. There is no appropriate reason not
to disable the flag.

This commit also updates other regression tests, which are not directly
related to this bug, for consistency with other fast-math flags.

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

After D137970, we do the fixable instruction conversion in place
so we don't need to worry about iterator invalidation. This lets
us to conversion and updates in a single loop.

Reviewed By: reames

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

Instead of creating a new instruction and copying operands, we can
use setDesc to convert in place.

Reviewed By: reames

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

If the immediate is a shifted mask, we will use a pair of shifts
and never materialize the immediate. Consider the immediate free.

Reviewed By: reames, luismarques

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

This patch replaces:

  return Optional<T>();

with:

  return None;

to make the migration from llvm::Optional to std::optional easier.
Specifically, I can deprecate None (in my source tree, that is) to
identify all the instances of None that should be replaced with
std::nullopt.

Note that "return None" far outnumbers "return Optional<T>();".  There
are more than 2000 instances of "return None" in our source tree.

All of the instances in this patch come from functions that return
Optional<T> except Archive::findSym and ASTNodeImporter::import, where
we return Expected<Optional<T>>.  Note that we can construct
Expected<Optional<T>> from any parameter convertible to Optional<T>,
which None certainly is.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

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

Since std::optional does not offer getPointer(), this patch replaces
X.getPointer() with &*X to make the migration from llvm::Optional to
std::optional easier.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

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

This patch is an alternative of D100091. It solved the problems in `f80` type lowering.

Reviewed By: LuoYuanke

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

Update pattern on Linux and Darwin for consistency.

This tool only parsed options after creating the LLVMContext.
Unfortunately, this means that some options, such as --opaque-pointers,
which are read when the LLVMContext is created are impossible to
set from the command line.  This patch moves the LLVMContext creation
after the option parsing.

tr is not available on Windows bot.

Indentation is significant for Sphinx. Lines with indentation after
a `.. option::` line are treated as explanations of the option.

Sphinx has the `option` directive. Most option descriptions
in `clang/docs/UsersManual.rst` used it but some didn't.
This commit changes the remaining option descriptions to use
the `option` directive. This makes a consistent view in HTML.

The `option` directive automatically creates a cross-reference target.
So labeling by `.. _opt_XXX:` is almost unnecessary. However, options
with and without `no-` (e.g. `-fno-show-column`/`-fshow-column`)
cannot be distinguish for the cross-reference. So some required
`.. _opt_XXX:` directives are kept unremoved.

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

Reviewed By: aartbik

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

This makes it possible for programmers to run IWYU and get more accurate
standard library inclusions. Prior to this commit, the following program
would be transformed thusly:

```cpp
// Before
 #include <algorithm>
 #include <vector>

void f() {
  auto v = std::vector{0, 1};
  std::find(std::ranges::begin(v), std::ranges::end(v), 0);
}
```

```cpp
// After
 #include <__algorithm/find.h>
 #include <__ranges/access.h>
 #include <vector>
...
```

There are two ways to fix this issue: to use [comment pragmas](https://github.com/include-what-you-use/include-what-you-use/blob/master/docs/IWYUPragmas.md)
on every private include, or to write a canonical [mapping file](https://github.com/include-what-you-use/include-what-you-use/blob/master/docs/IWYUMappings.md)
that provides the tool with a manual on how libc++ is laid out. Due to
the complexity of libc++, this commit opts for the latter, to maximise
correctness and minimise developer burden.

To mimimise...

The last use of emitCalleeSavedFrameMoves was removed on March 24,
2022 in commit 50a97aac.

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

Mysterious failures on the x86_64-linux-qemu, to be debugged.

This reverts commit 1dd54691.

Reviewed By: Peiming

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

Adds build files for libraries, tools, and tests -- everything except
the runtime.

Doesn't hook up bolt in the main BUILD.gn file yet -- I want to verify
that it builds on Linux, macOS, Windows before doing that. (I've only
checked on macOS so far.)

`ninja check-bolt` passes on macOS with this.
(I locally bumped the deployment target to macOS 10.12 for that. bolt/ uses
std::mutex quite a bit, which requires 10.12.)

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

This revision is a part of a series of patches extending
AddressSanitizer C++ container overflow detection capabilities by adding
annotations, similar to those existing in std::vector, to std::string
and std::deque collections. These changes allow ASan to detect cases
when the instrumented program accesses memory which is internally
allocated by the collection but is still not in-use (accesses before or
after the stored elements for std::deque, or between the size and
capacity bounds for std::string).

The motivation for the research and those changes was a bug, found by
Trail of Bits, in a real code where an out-of-bounds read could happen
as two strings were compared via a std::equals function that took
iter1_begin, iter1_end, iter2_begin iterators (with a custom comparison
function). When object iter1 was longer than iter2, read out-of-bounds
on iter2 could happen. Container sanitization would detect it.

This revision adds a new compiler-rt ASa...

This has the following advantages:
- std::shared_timed_mutex is macOS 10.12+ only. llvm::sys::RWMutex
  automatically switches to a different implementation internally
  when targeting older macOS versions.
- bolt only needs std::shared_mutex, not std::shared_timed_mutex.
  llvm::sys::RWMutex automatically uses std::shared_mutex internally
  where available.

std::shared_mutex and RWMutex have the same API, so no code changes
other than types and includes are needed.

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

This brings back previous SIMD functionality, but in a separate pass.
The idea is to improve this new pass incrementally, going beyond for-loops
to while-loops for co-iteration as welll (masking), while introducing new
abstractions to make the lowering more progressive. The separation of
sparsification and vectorization is a very good first step on this journey.

Also brings back ArmSVE support

Still to be fine-tuned:
  + use of "index" in SIMD loop (viz. a[i] = i)
  + check that all ops really have SIMD support
  + check all forms of reductions
  + chain reduction SIMD values

Reviewed By: dcaballe

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

Extends the global isel implementation to support G_ADD and G_SUB.

Reviewed By: arsenm, amyk

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

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

This pass has outgrown its original goal and is now going to be used to
expand certain memref operations before lowering.
Reflect that in the name.

The pass is now called expand-strided-metadata.

NFC

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

We would previously reject valid input where GNU attributes preceded the
standard attributes on top-level declarations. A previous attribute
handling change had begun rejecting this whilst GCC does honour this
layout. In practice, this breaks use of `extern "C"` attributed
functions which use both standard and GNU attributes as experienced by
the Swift runtime.

Objective-C deserves an honourable mention for requiring some additional
special casing. Because attributes on declarations and definitions
differ in semantics, we need to replicate some of the logic for
detecting attributes to declarations to which they appertain cannot be
attributed. This should match the existing case for the application of
GNU attributes to interfaces, protocols, and implementations.

Take the opportunity to split out the tooling tests into two cases: ones
which process macros and ones which do not.

Special thanks to Aaron Ballman for the many hints and extensive rubber
ducking that was involved in identifying the various places where we
accidentally dropped attributes.

Differential Revision: https://reviews.llvm.org/D137979
Fixes: #58229
Reviewed By: aaron.ballman, arphaman

GCC expands the pointer type in this conditional expression even for
template types _Up that are not arrays.  This raises an error when
std::decay<> is used with reference types (as is done in LLVM's
sources).  Using add_pointer<> causes GCC to only instantiate a
pointer type for array types.

Reviewed By: #libc, philnik, ldionne

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

This disables `RegisterCoalescer` pass at -O1, which currently runs for
all levels except for -O0, as a part of common optimization pipeline.

`RegisterCoalescer` pass degrades Wasm debug info quality by a
significant margin. When I use `LiveDebugValue` analysis, disabling this
increases the average PC ranges covered by 15% on Emscripten core
benchmarks (52% -> 66.8%). (Our code is currently not using
`LiveDebugValues` analysis at the moment, and the experiment was done on
a local setting that enabled it. I'm planning to upstream it soon.)

In Emscripten core benchmarks, disabling this at -O1 causes +4.5% in
code size and +1% in the number of locals. The number of globals stays
the same. I believe this tradeoff is acceptable given that -O1 is not
usually used in production builds and is often used for debugging when
the application size is very large.

The plan is to investigate and fix what's causing the degradation in
that pass, but for now disabling it seems like a low-hanging quick fix.

Reviewed By: dschuff

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

At the moment, getRangeRef may overflow the stack for very deeply nested
expressions.

This patch introduces a new getRangeRefIter function, which first builds
a worklist of N-ary expressions and phi nodes, followed by their
operands iteratively.

getRangeRef has been extended to also take a Depth argument and it
switches to use getRangeRefIter once the depth reaches a certain
threshold.

This ensures compile-time is not impacted in general. Note that
the iterative algorithm may lead to a slightly different evaluation
order, which could result in slightly worse ranges for cyclic phis.

https://llvm-compile-time-tracker.com/compare.php?from=23c3eb7cdf3478c9db86f6cb5115821a8f0f5f40&to=e0e09fa338e77e53242bfc846e1484350ad79773&stat=instructions

Fixes #49579.

Reviewed By: mkazantsev

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

This is just to make to follow-up diffs simpler

Reviewed By: ldionne, #libc, EricWF

Spies: EricWF, libcxx-commits

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

[PowerPC] Move PPCGenRegisterBankInfo.def into the directory where it would be if it was autogenerated

The vim Formatonsave integration is not working if we create a new file directly using vim.
eg: vi -V9t.log t.cpp

It will not able to format the buffer.

> Traceback (most recent call last):
>   File "<string>", line 1, in <module>
>   File "...clang/tools/clang-format/clang-format.py", line 156, in <module>
>     main()
>   File "...clang/tools/clang-format/clang-format.py", line 80, in main
>     with open(vim.current.buffer.name, 'r') as f:
> FileNotFoundError: [Errno 2] No such file or directory: '...t.cpp'

This patch check the file before we try to open it.

Reviewed By: owenpan

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

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

... in semantic highlighting.
These specifiers cannot be identified by simple lexing (since e.g.
variables with these names can legally be declared), which means they
should be semantic tokens.

Reviewed By: sammccall

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