Add VBRD/VMV vector instructions.  In order to do that, also support
VM512 registers and RV instruction format in MC layer.  Also add
regression tests for new instructions.

Reviewed By: simoll

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

Add LSV/LVS/LVM/SVM vector instructions and regression tests.
Also update AsmParser to support new format of operands.

Reviewed By: simoll

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

Support br_cc instruction comparing fp128 values.  Add a br_cc.ll
regression test for all kind of br_cc instructions.  And, clean
existing branch regression tests, this time.  Clean a brcond.ll
regression test for brcond instruction.  Remove mixed branch1.ll
regression test.

Reviewed By: simoll

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

Add an ISel pattern for fp128 select instruction and optimize generated
code for other types' select. instructions.  Add a regression test also.

Reviewed By: simoll

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

LLVM dialect has been defining Op arguments by deriving the `Arguments` ODS
class. This has arguably worse readability due to large indentation caused by
multiple derivations, and is inconsistent with other ODS files. Use the `let
arguments` form instead.

Reviewed By: rriddle

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

This patch breaks Orc.h up into Orc.h, LLJIT.h and OrcEE.h.

Orc.h contain core Orc utilities.
LLJIT.h contains LLJIT specific types and functions.
OrcEE.h contains types and functions that depend on ExecutionEngine.

The intent is that these headers should match future library divisions: Clients
who only use Orc.h should only need to link againt the Orc core libraries,
clients using LLJIT.h will also need to link against LLVM core, and clients
using OrcEE.h will also have to link against ExecutionEngine.

In addition to breaking up the Orc.h header this patch introduces functions to:
(1) Set the object linking layer creation function on LLJITBuilder.
(2) Create an RTDyldObjectLinkingLayer instance (particularly for use in (1)).
(3) Register JITEventListeners with an RTDyldObjectLinkingLayer.

Together (1), (2) and (3) can be used to force use of RTDyldObjectLinkingLayer
as the underlying JIT linker for LLJIT, rather than the platform default, and
to register event listeners with the RTDyldObjectLinkingLayer.

Patch by Andres Freund. Thanks Andres!

Also tweaks the definition of TryToGenerate to make it dovetail more neatly
with the new function.

C API clients can now define a custom definition generator by providing a
callback function (to implement DefinitionGenerator::tryToGenerate) and context
object. All arguments for the DefinitionGenerator::tryToGenerate method have
been given C API counterparts, and the API allows for optionally asynchronous
generation.

This will allow C API clients to return errors from callbacks. This
functionality will be used in upcoming Orc C-bindings functions.

Based on a patch by Andres Freund. Thanks Andres!

The DefinitionGenerator class has been moved out of JITDylib. This updates
the C API type and function names to reflect that.

Patch by Andres Freund. Thanks Andres!

Symbol string pool entries are ref counted, but not automatically cleared.
This can cause the size of the pool to grow without bound if it's not
periodically cleared. These functions allow that to be done via the C API.

The LLVMOrcLLJITAddLLVMIRModule function was leaking its
LLVMOrcThreadSafeModuleRef argument. Wrapping the argument in a unique_ptr
fixes this.

This patch moves definition generation out from the session lock, instead
running it under a per-dylib generator lock. It also makes the
DefinitionGenerator::tryToGenerate method optionally asynchronous: Generators
are handed an opaque LookupState object which can be captured to stop/restart
the lookup process.

The new scheme provides the following benefits and guarantees:

(1) Queries that do not need to attempt definition generation (because all
    requested symbols matched against existing definitions in the JITDylib)
    can proceed without being blocked by any running definition generators.

(2) Definition generators can capture the LookupState to continue their work
    asynchronously. This allows generators to run for an arbitrary amount of
    time without blocking a thread. Definition generators that do not need to
    run asynchronously can return without capturing the LookupState to eliminate
    unnecessary recursion and improve lookup performance.

(3) Definition generators still do not need to worry about concurrency or
    re-entrance: Since they are still run under a (per-dylib) lock, generators
    will never be re-entered concurrently, or given overlapping symbol sets to
    generate.

Finally, the new system distinguishes between symbols that are candidates for
generation (generation candidates) and symbols that failed to match for a query
(due to symbol visibility). This fixes a bug where an unresolved symbol could
trigger generation of a duplicate definition for an existing hidden symbol.

This will make it easier to implement asynchronous definition generators.

MaterializationResponsibility, JITDylib, and ExecutionSession collectively
manage the OrcV2 core JIT state. Responsibility for maintaining and
updating this state has previously been spread among these classes, resulting
in implementations that are each non-trivial, but all tightly coupled. This has
in turn made reading the code and reasoning about state update and locking
rules difficult.

The core state model can be simplified by thinking of
MaterializationResponsibility and JITDylib as facets of ExecutionSession. This
commit is the first in a series intended to refactor Core.cpp to reflect this
model. Operations on MaterializationResponsibility and JITDylib will forward to
implementation methods inside ExecutionSession. Raw state will remain with the
original classes, but in most cases will only be modified by the
ExecutionSession.

Differential revision: https://reviews.llvm.org/D89553

(Re)add DW_AT_specification and DW_AT_object_pointer attributes. These
were removed in fa89f641, as they were bogus due to bad test case
reduction.

Differential revision: https://reviews.llvm.org/D89114

All existing SCEV cast types operate on integers.
D89456 will add SCEVPtrToIntExpr cast expression type.
I believe this is best for consistency.

Reviewed By: mkazantsev

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

Usage of nested parallel regions were not working correctly and leading
to assertion failures. Fix contains the following changes,
1) Don't set the insertion point in the body callback.
2) Save the continuation IP in a stack and set the branch to
continuationIP at the terminator.

Reviewed By: SouraVX, jdoerfert, ftynse

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

This patch adds support for renaming variable templates.

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

In certain places in llvm/lib/CodeGen we were relying upon the TypeSize
comparison operators when in fact the code was only ever expecting
either scalar values or fixed width vectors. This patch changes a few
functions that were always expecting to work on scalar or fixed width
types:

1. DAGCombiner::mergeTruncStores - deals with scalar integers only.
2. DAGCombiner::ReduceLoadWidth - not valid for vectors.
3. DAGCombiner::createBuildVecShuffle - should only be used for
   fixed width vectors.
4. SelectionDAGLegalize::ExpandFCOPYSIGN and
   SelectionDAGLegalize::getSignAsIntValue - only work on scalars.

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

This may be fixed in the future, but since redefinition in OrcV2 requires more
manual work on the JIT client's part it was left out of the most recent update
to the tutorials.

previously, we missed to rename occurrences to explicit function template
specilizations.

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

In certain places in llvm/lib/CodeGen we were relying upon the TypeSize
comparison operators when in fact the code was only ever expecting
either scalar values or fixed width vectors. I've changed some of these
places to use the equivalent scalar operator.

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

In CodeGenDAGPatterns.cpp we were relying upon TypeSize comparison
operators for ordering types, when we can actually just use the known
minimum size since the scalable property is already being taken into
account. Also, in TypeInfer::EnforceSameSize I fixed some implicit
TypeSize->uint64_t casts by changing the code to test the equality
of TypeSize objects instead.

In other places I have replaced calls to getSizeInBits() with
getFixedSizeInBits() because we are only ever expecting integer values.

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

MSVC doesn't seem to like capturing references to variables in lambdas passed to
the variable's constructor. This should fix the windows bots that have been
unable to build the new ResourceTracker unit test.

In certain places in the code we can never end up in a situation where
we're mixing fixed width and scalable vector types. For example,
we can't have truncations and extends that change the lane count. Also,
in other places such as GenWidenVectorStores and GenWidenVectorLoads we
know from the behaviour of FindMemType that we can never choose a vector
type with a different scalable property.

In various places I have used EVT::bitsXY functions instead of
TypeSize::isKnownXY, where it probably makes sense to keep an assert
that scalable properties match.

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

In many places in the AArch64 backend we are comparing TypeSize objects,
but in fact we are only ever expecting fixed width types. I've changed
all such comparisons to use their integer equivalents by replacing
calls to getSizeInBits() with getFixedSizeInBits(), etc.

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

AllReduceLowering is currently the only GPU rewrite pattern, but more are coming. This is a preparation change.

Reviewed By: herhut

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