This is in preparation for https://reviews.llvm.org/D129857.

This is for consistency with `Value::replaceUsesWithIf`.

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

This patch achieves this by building an AST and invoking main file
callbacks on each update, in addition to preamble updates.

It means we might have some extra AST builds now (e.g. if an update was
with a stale preamble and there were no reads on it, we would only build
an AST once we had the fresh preamble. Now we'll build 2, once with the
stale preamble and another with the fresh one, but we'll have one more
diagnostics cycle in between.).

This patch preserves forward progress of diagnostics by always using the
latest main file contents when emitting diagnostics after preamble
builds. It also guarantees eventual consistency:
- if an update doesn't invalidate preamble, we'll emit diagnostics with
  fresh preamble already.
- if an update invalidates preamble, we'll first emit diagnostics with
  stale contents, and then once the preamble build finishes it'll emit
  diagnostics (as preamble has changed) with newest version.

This has implications on parsing callbacks, as previously onMainAST
callback was called at most once, now it can be called up to 2 times.
All of the existing clients can already deal with callback firing
multiple times.

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

Translates diagnostics from baseline preamble to relevant modified
contents.

Translation is done by looking for a set of lines that have the same
contents in diagnostic/note/fix ranges inside baseline and modified
contents.

A diagnostic is preserved if its main range is outside of main file or
there's a translation from baseline to modified contents. Later on fixes
and notes attached to that diagnostic with relevant ranges are also
translated and preserved.

Depends on D143095

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

Depends on D143093

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

That way we can stop generating false macro redefinition diagnostics.

Depends on D142890

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

Also wire it up for use with patched preambles and introduce test cases
for behaviour we'd like to improve.

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

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

The function arguments and results type will have the default memory space.

Reviewed By: springerm

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

When the associated expression came from a moved variable, the
type of the moved variable may not exactly match the hlfir.associate
result and cannot be re-used directly. Insert fir.convert/fir.box_addr
as needed.

Reviewed By: clementval

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

D139469 "[AMDGPU] Enable OMod on more VOP3 instructions" caused an
assertion failure when trying to fold into src2 of V_FMAC_F16. It would
temporarily convert the instruction to V_FMA_F16_gfx9 and add an opsel
operand, but if the fold still failed then it would forget to remove the
opsel operand.

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

Split out of D140908 as suggested, and added unit testing.

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

Reviewed By: Mordante, #libc

Spies: arichardson, libcxx-commits

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

SimplifyCFG currently drops !nontemporal metadata when sinking
common instructions. With this change, SimplifyCFG and similar
transforms will preserve !nontemporal metadata as long as it is
set on both original instructions.

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

Use proper relocation for aarch64

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

RISC-V vector instruction has register overlapping constraint for certain
instructions, and will cause illegal instruction trap if violated, we use
early clobber to model this constraint, but it can't prevent register allocator
allocated same or overlapped if the input register is undef value, so convert
IMPLICIT_DEF to temporary pseudo could prevent that happen, it's not best way
to resolve this. Ideally we should model the constraint right, but before we
model the constraint right, it's the approach to prevent that happen.

See also: https://github.com/llvm/llvm-project/issues/50157

Reviewed By: craig.topper

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

Just like with integers, we can treat zero fp buildvector as legal so that they
can be recognized in tablegen patterns using immAllZerosV.

The instruction regexp "^INSv" for the insert gen-reg-to-element was also
matching the element-to-element instruction, which only has a latency of 2 and
not 5, so we were getting that wrong.

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

The vendor-defined XTheadSync (no comparable standard extension exists
at the time of writing) extension adds multi-core synchronization
instructions.

It is supported by the C9xx cores (e.g., found in the wild in the
Allwinner D1) by Alibaba T-Head.

The current (as of this commit) public documentation for this
extension is available at:
  https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.2.2/xthead-2023-01-30-2.2.2.pdf

Support for these instructions has already landed in GNU Binutils:
  https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=547c18d9bb95571261dbd17f4767194037eb82bd

Depends on D144496

Reviewed By: craig.topper

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

It's less clear with scalable vectors than fixed length vectors that
interleaving exposes more ILP, as scalable vectors can be thought of a
sort of hardware form of interleaving, especially with larger LMULs.
This also addresses the unexpected additional unrolling that occurs when
using larger LMULs in the loop vectorizer.

Reviewed By: craig.topper

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

In order to allow targets to disable interleaving for scalable vectors, pass the entire VF's ElementCount to getMaxInterleaveFactor.
This is based off of the approach used here: https://repo.hca.bsc.es/gitlab/rferrer/llvm-epi/-/commit/8d36708507b3c378078b9fe364bc548354aaec86

The plan would then be to disable interleaving on scalable VFs on RISC-V in a follow up patch.
See https://reviews.llvm.org/D143723#4132349

Reviewed By: reames

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

Reverse the operand ordering to ? rhs : lhs.

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

The vendor-defined XTHeadCmo (there are some similarities with the
Zicbom standard extension) extension adds cache management instructions.

It is supported by the C9xx cores (e.g., found in the wild in the
Allwinner D1) by Alibaba T-Head.

The current (as of this commit) public documentation for this
extension is available at:
  https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.2.2/xthead-2023-01-30-2.2.2.pdf

Support for these instructions has already landed in GNU Binutils:
  https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=a9ba8bc2d396fb8ae2b892f3bc6be8cdfe4b555c

Reviewed By: craig.topper

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

Avoid replacing one adr instruction with two adrp+add by utilizing linker-provided nops
when they are present. By doing so we preserve relative offsets of next instructions
in a function which reduces chances to break undetected jump tables. This commit makes
release-mode lld-linked clang, lld and etc work after BOLT.

Reviewed By: rafauler, yota9

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

There doesn't appear to be any reason why this attribute is
inferred separately from other ones that use AttributeInferer.

This callback is triggered by `finalizeRootUpdate`. This allows listeners to listen for in-place op modifications without creating a new RewriterBase subclass.

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

These functions will be used in a subsequent change. Also some minor refactoring.

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

Allow an optional `RewriterBase::Listener` to be attached to greedy pattern rewrites, so that clients can listen for IR modifications.

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

The functionality in MultilibSet for creating it is tied to its current
implementation. Putting that code in a separate class is an enabler for
changing the MultilibSet implementation.

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

Specifying --sysroot prevents libclang_rt from being located in standard
library directories.

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

This partially reverts a regression introduced in 8f25e382 for
AArch64 targets. In particular, we restore the logic of `(abs (sub nsw
x, y)) -> abds(x, y)` for all targets except X86, which keeps the logic
introduced in 8f25e382. See also https://reviews.llvm.org/D142288.

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

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

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

- That saves the overhead of operand type querying.

This patch includes the commit 01adf96e and a fix of unhandled declaration
references.

When looking up base classes, Clang first checks whether a base class is a
template and takes the specialized template based on it. However, the base class
might be instantiated, and the above behavior can lose information.

This patch fixes the problem by first checking whether a base class is a record
declaration, so the instantiated one will be taken.

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

Use hasAttrSomewhere() and directly return Argument from the
helper.

```
  OpBuilder           OpBuilder::Listener
      ^                        ^
      |                        |
RewriterBase        RewriterBase::Listener
```

* Clients can listen to IR modifications with `RewriterBase::Listener`.
* `RewriterBase` no longer inherits from `OpBuilder::Listener`.
* Only a single listener can be registered at the moment (same as `OpBuilder`).

RFC: https://discourse.llvm.org/t/rfc-listeners-for-rewriterbase/68198

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

This runtime API can be used to lower any flavor of array constructors,
but is mainly intended to be used with:

- array constructors for which the extent or length parameters cannot
 be computed without lowering some ac-value or ac-implied-do-control
 that cannot be pre-evaluated.

- array constructors of a derived type with allocatable component where
 copy is not trivial or PDTS.

Example of use cases:
 - `[((i+j,i=1, ifoo()), j=1,n)]` where ifoo() is not pure.
 - `[return_allocatable_array(), return_allocatable_array()]`

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