This commits adds a basic LSP server for MLIR that supports resolving references and definitions. Several components of the setup are simplified to keep the size of this commit down, and will be built out in later commits. A followup commit will add a vscode language client that communicates with this server, paving the way for better IDE experience when interfacing with MLIR files.

The structure of this tool is similar to mlir-opt and mlir-translate, i.e. the implementation is structured as a library that users can call into to implement entry points that contain the dialects/passes that they are interested in.

Note: This commit contains several files, namely those in `mlir-lsp-server/lsp`, that have been copied from the LSP code in clangd and adapted for use in MLIR. This copying was decided as the best initial path forward (discussed offline by several stake holders in MLIR and clangd) given the different needs of our MLIR server, and the one for clangd. If a strong desire/need for unification arises in the future, the existence of these files in mlir-lsp-server can be reconsidered.

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

This information isn't useful for general compilation, but is useful for building tools that process .mlir files. This class will be used in a followup to start building an LSP language server for MLIR.

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

This fixed issue introduced in 16af9739
and 796feb61.

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

Broken in https://lab.llvm.org/buildbot/#/builders/96/builds/6933

We don't really need to run this test on arm, but would be worth fixing
it later.

This makes the memcpy-memcpy and memcpy-memset optimizations work for
variable sizes as long as they are equal, relaxing the old restriction
that they are constant integers. If they're not equal, the old
requirement that they are constant integers with certain size
restrictions is used.

The implementation works by pushing the length tests further down in the
code, which reveals some places where it's enough that the lengths are
equal (but not necessarily constant).

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

This reverts commit 05eeed96 and after
fixing the impacted lldb tests in 5d1c43f3.

  [Driver] Support default libc++ library location on Darwin

  Darwin driver currently uses libc++ headers that are part of Clang
  toolchain when available (by default ../include/c++/v1 relative to
  executable), but it completely ignores the libc++ library itself
  because it doesn't pass the location of libc++ library that's part
  of Clang (by default ../lib relative to the exceutable) to the linker
  always using the system copy of libc++.

  This may lead to subtle issues when the compilation fails because the
  headers that are part of Clang toolchain are incompatible with the
  system library. Either the driver should ignore both headers as well as
  the library, or it should always try to use both when available.

  This patch changes the driver behavior to do the latter which seems more
  reasonable, it makes it easy to test and use custom libc++ build on
  Darwin while still allowing the use of system version. This also matches
  the Clang driver behavior on other systems.

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

Add option -fgpu-inline-threshold for inline threshold for device compilation only.

Reviewed by: Artem Belevich

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

It's too slow, which delays the posting of CI results to Phabricator
when another step in the same stage fails.

Now that we have a more efficient implementation of storeTags(),
we should start using it from resizeTaggedChunk(). With that, plus
a new storeTag() function, resizeTaggedChunk() can be made generic,
and so can prepareTaggedChunk(). Make it so.

Now that the functions are generic, move them to combined.h so that
memtag.h no longer needs to know about chunks.

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

DC GZVA can operate on multiple granules at a time (corresponding to
the CPU's cache line size) so we can generally expect it to be faster
than STZG in a loop.

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

This diff ass postRunCommands, which are the counterpart of the preRunCommands. TThey will be executed right after the target is launched or attached correctly, which means that the targets can assume that the target is running.

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

Trying to evaluate a GEP would assert with
  "Ty == cast<PointerType>(C->getType()->getScalarType())->getElementType()"
because the type of the pointer we would evaluate the GEP argument to
would be a different type than the GEP was expecting. We should treat
pointer stripping as a bitcast.

The test adds a redundant GEP that would crash due to type mismatch.

Reviewed By: rnk

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

Use the clang compiler from the SDK to build the simulator test programs
to ensure we pick up the correct libc++.

MSVC doesn't accept division by zero.

Reviewed By: Meinersbur

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

Helps with debugging invalid handcrafted IR.

Reviewed By: rnk

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

As discussed here: https://reviews.llvm.org/D100523#inline-951543

Reviewed By: #lld-macho, thakis, alexshap

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

This reverts commit 9423f782.

A performance regression with this patch has been reported at
https://reviews.llvm.org/rG9423f78240a2#990953. Reverting for now.

An empty macro that expands to just `... else ;` can get
warnings from some compilers (e.g. GCC's -Wempty-body).

Reviewed By: cryptoad, vitalybuka

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

`RichManglingContext::FromCxxMethodName` allocates a m_cxx_method_parser, but never deletes it.

This fixes a `-DLLVM_USE_SANITIZER=Leaks` failure.

Reviewed By: teemperor

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

Discovered during attributor testing comparing stats with
and without the attributor. Willreturn should not be inferred
for nonexact definitions.

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

If these sizes do not match, asan will not work as expected. Previously, we added compile-time checks for non-iOS platforms. We check at run time for iOS because we get the max VM size from the kernel at run time.

rdar://76477969

Reviewed By: delcypher

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

Fix for PR49984
This was discovered during Attributor testing.
Memset was always created with alignment of 1
and in case when strncpy alignment was changed
it triggered an assertion in the AttrBuilder.
Memset will now be created with appropriate alignment.

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

This will prevent fusion that spains all dims and generates
(d0, d1, ...) -> () reshape that isn't legal

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

https://alive2.llvm.org/ce/z/zWL_VQ

Removes the "reviews." part of the links as suggested by @ldionne in
D100707.

There were some recent header changes, and now some std classes
are no longer available in ScopDetection.cpp with the pre-existing
includes.

PR50049 demonstrated an infinite loop between OR(SHUFFLE,SHUFFLE) <-> BLEND(SHUFFLE,SHUFFLE) patterns.

The UNDEF elements were allowing a combined shuffle mask to be widened which lost the undef element, resulting us needing to use the BLEND pattern (as the undef element would need to be zero for the OR pattern). But then bitcast folds would re-expose the undef element allowing us to use OR again.....

Add initial tests for reading register sets from core dumps.  This
includes a C++ program to write registers and dump core, resulting core
dumps for Linux, FreeBSD and NetBSD, and the tests to verify them.

The tests are split into generic part, verifying user-specified register
values, and coredump-specific tests that verify memory addresses that
differ for every dump.

At this moment, all platforms support GPRs and FPRs up to XMM for amd64
target.  The i386 target does not work on NetBSD at all, and is missing
FPRs entirely on FreeBSD.

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

This load command records a range spanning from the end of the load
commands to the end of the `__TEXT` segment. Presumably the kernel will encrypt
all this data.

Reviewed By: #lld-macho, thakis

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

The implicitly generated mappings for allocation/deallocation in mappers
runtime should be mapped as implicit, also no need to clear member_of
flag to avoid ref counter increment. Also, the ref counter should not be
incremented for the very first element that comes from the mapper
function.

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

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

Implements parts of:
    * P0896R4 The One Ranges Proposal`

Depends on D99873.

Reviewed By: ldionne, #libc

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

external.c defines stub functions that are never used because of how
Polly uses PPCG. Unfortunately, they are declared as functions without
return values or parameters which does not match their declarations.
Since they are never called, this was usually not a problem, but an LTO
build gets confused with differently declared functions, or in case of
pet_options_args, a global variable declaration that is defined as a
function

Resolve by including the declaring headers in external.c which forces
the declaration and definition to match at compile-time.

This fixes llvm.org/50021

This was raised in D94511.

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

Simplify the test code, and drive-by also test that these algorithms
return the right iterator as their return value.

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