This patch adds the assembly/disassembly for the following instructions:

pmov : Move predicate to vector
pmov : Move vector to predicate

The reference can be found here:
https://developer.arm.com/documentation/ddi0602/2022-09

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

Reverted in b22d80dc.

Move getDebugValueLoc so that it can be accessed from DebugInfo.h for the
Assignment Tracking patch stack and remove redundant parameter Src.

Reviewed By: jryans

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

This reverts commit 279fe628, which causes
non-linear compilation time growth. See https://reviews.llvm.org/D136565#3914755

Need to check if the insertelement mask size is reached during cost analysis to avoid compiler crash.

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

Reapplies 87a20868 (which was reverted in 656f1d8b).
Fix for scalable vectors in getInsertIndex merged in 46d53f45.

Reviewed By: ABataev

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

RefTypes are distinct categories for each reference to a symbol. They
are signals indicating strength of a reference, that'll enable different
decision making based on the finding being provided.

There are 3 kinds of ref types:
- Explicit, the reference is spelled in the code.
- Implicit, the reference is not directly visible in the code.
- Ambigious, the reference exists but can't be proven as used (e.g.
  overloads brought in by a using decl but not used by the code).

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

Buildbot failure:
https://lab.llvm.org/buildbot/#/builders/36/builds/26925

Review & commit:
https://reviews.llvm.org/D132224
https://reviews.llvm.org/rG171f7024cc82e8702abebdedb699d37b50574be7

This reverts commit 281f2134.

Previously reverted in 41f5a000. Fold in
D133576 previously reverted in d29d5ffb.

---

The Assignment Tracking debug-info feature is outlined in this RFC:

https://discourse.llvm.org/t/
rfc-assignment-tracking-a-better-way-of-specifying-variable-locations-in-ir

Overview
It's possible to find intrinsics linked to an instruction by looking at the
MetadataAsValue uses of the attached DIAssignID. That covers instruction ->
intrinsic(s) lookup. Add a global DIAssignID -> instruction(s) map which gives
us the ability to perform intrinsic -> instruction(s) lookup. Add plumbing to
keep the map up to date through optimisations and add utility functions
including two that perform those lookups. Finally, add a unittest.

Details
In llvm/lib/IR/LLVMContextImpl.h add AssignmentIDToInstrs which maps DIAssignID
* attachments to Instruction *s. Because the DIAssignID * is the key we can't
use a TrackingMDNodeRef for it, and therefore cannot easily update the mapping
when a temporary DIAssignID is replaced.

Temporary DIAssignID's are only used in IR parsing to deal with metadata
forward references. Update llvm/lib/AsmParser/LLParser.cpp to avoid using
temporary DIAssignID's for attachments.

In llvm/lib/IR/Metadata.cpp add Instruction::updateDIAssignIDMapping which is
called to remove or add an entry (or both) to AssignmentIDToInstrs. Call this
from Instruction::setMetadata and add a call to setMetadata in Intruction's
dtor that explicitly unsets the DIAssignID so that the mappging gets updated.

In llvm/lib/IR/DebugInfo.cpp and DebugInfo.h add utility functions:

    getAssignmentInsts(const DbgAssignIntrinsic *DAI)
    getAssignmentMarkers(const Instruction *Inst)
    RAUW(DIAssignID *Old, DIAssignID *New)
    deleteAll(Function *F)
    deleteAssignmentMarkers(const Instruction *Inst)

These core utils are tested in llvm/unittests/IR/DebugInfoTest.cpp.

Reviewed By: jmorse

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

None of Haswell/Broadwell/Skylake/Icelake treat CVTTSS2SI64rm differently from CVTSS2SI64rm (or the AVX variants)

Confirmed with Agner, uops.info and Intel AoM

This revision fixes typos where there are 2 consecutive words which are duplicated.
There should be no code changes in this revision (only changes to comments and docs).
Do let me know if there are any undesirable changes in this revision. Thanks.

The occurrences are roots for finding used headers, like walkAST.
Includes are the targets we're matching used headers against.

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

This reverts commit 632a389f.

This relands commit
1834a310.

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

D137341

This patch changes AArch64 + `__GNUC__` to use `__sync` builtins to
implement internal atomic macros just like for Unix, because mingw-w64
is missing some of the intrinsics which the MSVC codepath is using.

Then some remaining intel-only functions are removed from dllexport to
fix linking.

This should fix https://github.com/llvm/llvm-project/issues/56349.

Reviewed By: natgla

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

Mention that the LLVM/clang triple must be provided if the trace will be
consumed via `SBTraceCursor`

Test Plan:

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

This reverts commit 1834a310.

Reviewed By: ABataev

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

This patch adds the assembly/disassembly for the following instructions:

  SQRSHR (four registers): Multi-vector signed saturating rounding shift right narrow by immediate.
         (two registers): Multi-vector signed saturating rounding shift right narrow by immediate.
  SQRSHRN: Multi-vector signed saturating rounding shift right narrow by immediate and interleave.
  SQRSHRU (four registers): Multi-vector signed saturating rounding shift right unsigned narrow by immediate.
          (two registers): Multi-vector signed saturating rounding shift right unsigned narrow by immediate.
  SQRSHRUN: Multi-vector signed saturating rounding shift right unsigned narrow by immediate and interleave.
  UQRSHR (four registers): Multi-vector unsigned saturating rounding shift right narrow by immediate
         (two registers): Multi-vector unsigned saturating rounding shift right narrow by immediate.
  UQRSHRN: Multi-vector unsigned saturating rounding shift right narrow by immediate and interleave.

The reference can be found here:

https://developer.arm.com/documentation/ddi0602/2022-09

Reviewed By: paulwalker-arm

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

This was done as a test for D137302 and it makes sense to push these changes

Reviewed By: dblaikie

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

This revision fixes typos where there are 2 consecutive words which are
duplicated. There should be no code changes in this revision (only
changes to comments and docs). Do let me know if there are any
undesirable changes in this revision. Thanks.

LoopPredication might be able to turn such checks (which are
not necessarily are done on IV) into loop invariant checks.

Declutter applyPreexistingWaitcnt() a little by abstracting the code
that updates the operands to S_WAITCNT and S_WAITCNT_VSCNT instructions
into discrete functions.

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

The values used here are never null.

Caused by legacy min/max combines (select + cmp) asking for legalizer info
in prelegalizer (D135047 added combine to all_combines).
Combine still does not work for AMDGPU since destination opcode is custom,
not legal. Similar combine works on DAG since it asks for legal or custom.

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

When the branch target is out of the range represented by the current
branch instruction's immediate, branch relaxation is required. There
are three types of immediate for branch instructions on LoongArch,
including simm16, simm21 and simm26. And the real branch target
address is PC + sext(simmXX << 2). In addition, the indirect branch
way is implemented to support larger branch target.

BranchRelaxation pass calls `RenumberBlocks` to renumber all of the
machine basic blocks in the function. So the machine basic blocks
number changed in some test cases.

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

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

Updated the RUN line in several test cases to use the new PM syntax
  opt -passes=<pipeline>
instead of the deprecated syntax
  opt -pass1 -pass2

Updated the RUN line in several test cases to use the new PM syntax
  opt -passes=<pipeline>
instead of the deprecated syntax
  opt -pass1 -pass2

This was not a complete cleanup in clang/test. But just a swipe using
some simple search-and-replace. Mainly for RUN lines involving
-mem2reg, -instnamer and -early-cse.

Most constructors and destructors in CFG.h already specify const arguments, but some are missing this.

Reviewed By: gribozavr2, krasimir

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

This patch adds the assembly/disassembly for the following instructions:

dupq : Broadcast indexed element within each quadword vector segment (unpredicated)
extq : Extract vector segment from each pair of quadword vector segments

The reference can be found here:
https://developer.arm.com/documentation/ddi0602/2022-09

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

Reviewed By: bkramer

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

The documentation already has examples of this, and it allows for
using nicer C++ types when defining native Rewrites.

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

When all operands or results are variadic, zero values is a perfectly valid behavior
to expect, and we shouldn't force the user to provide values in this case. For example,
when creating a call or a return operation we often don't want/need to provide return
values.

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

This allows for constructing type and value ranges from various sub elements,
which makes it easier to construct operations that take a range as an operand
or result type. Range construction is currently limited to within rewrites, to match
the current constraint on the PDL side.

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

This commit adds support for building a concatenated range from
a given set of elements, either single element or other ranges, within a
rewrite. We could conceptually extend this to support constraining
input ranges, but the logic there is quite a bit more complex so it is
left for later work when a need arises.

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