Reviewed By: erichkeane

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

It's been over two years since I added the temporary error, so I think
it's reasonable to remove it now.

If we ignore droppable users everything only used in llvm.assume (among
other things) is going to be deleted as dead. This is not helpful.
Instead we want to only delete things we actually don't need anymore. A
follow up will deal with loads in a smarter way.

- https://reviews.llvm.org/D122619 bumped zlib version but didn't change
  the hash

- Added new header from https://reviews.llvm.org/D108438

144 = 16 * 9

For types where s16 is legal.

It may be interesting to break these down into 16-bit chunks rather than 32
or 64 bits.

Add tests for some opcodes, just so we get some test coverage drawing attention
to this.

After enabling the LLDB index cache in production we discovered that some distributed build systems play with the modification times of any .o files that were downloaded from the build cache. This was causing the LLDB index cache to read the wrong cache file for files that didn't have a UUID as all of the modfication times were set to the same value by the build system. When new .o files were downloaded, the only unique identifier was the mod time which were all the same, and we would load an older cache for the updated .o file. So disabling caching of files that have no UUIDs for now until we can create a more solid solution.

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

158 = 32 * 5 - 2

This is a wide type which may benefit from a different widening scheme than
types which are multiples of 64. For example, if 32-bit and 64-bit scalars
are both allowed, and a type is a multiple of 32, or is closer to a multiple
of 32, it *may* be better to

- Widen to the wide multiple of 32
- Break up the type into 32-bit chunks

Anyway, we don't have any test coverage for this at all, so for the sake of
making sure we test it, let's add some test coverage.

The `LLVMBitCodes.h` header contains various enums that are updated whenever LLVM's bitcode fundamentally changes. It would be nice to track these changes in a semi-automated way, so that external tools that attempt to parse LLVM's bitstream and bitcode can remain in sync.

Before this change, `LLVMBitCodes.h` had a single dependency -- it needed the `FIRST_APPLICATION_BLOCKID` enum value from `BitCodes.h`. `BitCodes.h`, in turn, had a whole tree of include dependencies that boiled down to `llvm-config.h`, meaning that it was impossible to dump the AST of either file without having a partial or full LLVM build tree already present.

To eliminate that requirement, this patch introduces a new leaf-only header, `BitCodeEnums.h`, which includes the "core" enums originally in `BitCodes.h`. `LLVMBitCodes.h` and `BitCodes.h` both include this new header in turn, preserving the current header relationships while allowing `LLVMBitCodes.h` to be dumped fully independently with a command like this (run from the repository root):

```
clang -fsyntax-only -x c++ -Illvm/include -Xclang -ast-dump=json -Xclang -ast-dump-filter -Xclang llvm::bitc::BlockIDs llvm/include/llvm/Bitcode/LLVMBitCodes.h
```

I recognize that this is a pretty unusual change and perhaps not a guarantee that the LLVM authors would like to make in the general case (i.e., that individual files within LLVM can have their AST dumped with minimal dependencies). However, I believe the criticality/limited scope of the file(s) in this patch warrants an exception. Please let me know if there's any other information I can provide, or anything else I can do to improve this patch!

Reviewed By: tejohnson

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

This reverts commit 64f659be.

An invalid tensor.expand_shape op is generated with the commit. To repro:

$ mlir-opt -canonicalize a.mlir

```
func @foo(%0: tensor<1x1xf32>, %1: tensor<1x1xf32>, %2: tensor<1x1xf32>) -> tensor<1x1xf32> {
  %cst = arith.constant 0.000000e+00 : f32
  %3 = linalg.init_tensor [8, 1] : tensor<8x1xf32>
  %4 = linalg.fill ins(%cst : f32) outs(%3 : tensor<8x1xf32>) -> tensor<8x1xf32>
  %5 = tensor.collapse_shape %0 [] : tensor<1x1xf32> into tensor<f32>
  %6 = tensor.insert_slice %5 into %4[0, 0] [1, 1] [1, 1] : tensor<f32> into tensor<8x1xf32>
  %7 = linalg.init_tensor [8, 1] : tensor<8x1xf32>
  %8 = linalg.fill ins(%cst : f32) outs(%7 : tensor<8x1xf32>) -> tensor<8x1xf32>
  %9 = tensor.collapse_shape %2 [] : tensor<1x1xf32> into tensor<f32>
  %10 = tensor.insert_slice %9 into %8[0, 0] [1, 1] [1, 1] : tensor<f32> into tensor<8x1xf32>
  %11 = tensor.collapse_shape %6 [[0, 1]] : tensor<8x1xf32> into tensor<8xf32>
  %12 = linalg.init_tensor [8] : tensor<8xf32>
  %13 = linalg.generic {indexing_maps = [affine_map<(d0) -> (d0)>, affine_map<(d0) -> (d0)>], iterator_types = ["parallel"]} ins(%11 : tensor<8xf32>) outs(%12 : tensor<8xf32>) {
  ^bb0(%arg3: f32, %arg4: f32):
    linalg.yield %arg3 : f32
  } -> tensor<8xf32>
  %14 = tensor.expand_shape %13 [[0, 1, 2, 3]] : tensor<8xf32> into tensor<1x1x8x1xf32>
  %15 = tensor.collapse_shape %1 [] : tensor<1x1xf32> into tensor<f32>
  %16 = linalg.init_tensor [] : tensor<f32>
  %17 = linalg.generic {indexing_maps = [affine_map<() -> ()>, affine_map<() -> ()>], iterator_types = []} ins(%15 : tensor<f32>) outs(%16 : tensor<f32>) {
  ^bb0(%arg3: f32, %arg4: f32):
    linalg.yield %arg3 : f32
  } -> tensor<f32>
  %18 = tensor.expand_shape %17 [] : tensor<f32> into tensor<1x1x1x1xf32>
  %19 = tensor.collapse_shape %10 [[0, 1]] : tensor<8x1xf32> into tensor<8xf32>
  %20 = linalg.init_tensor [8] : tensor<8xf32>
  %21 = linalg.generic {indexing_maps = [affine_map<(d0) -> (d0)>, affine_map<(d0) -> (d0)>], iterator_types = ["parallel"]} ins(%19 : tensor<8xf32>) outs(%20 : tensor<8xf32>) {
  ^bb0(%arg3: f32, %arg4: f32):
    linalg.yield %arg3 : f32
  } -> tensor<8xf32>
  %22 = tensor.expand_shape %21 [[0, 1, 2, 3]] : tensor<8xf32> into tensor<1x1x8x1xf32>
  %23 = linalg.mmt4d {comment = "f32*f32->f32, aarch64, matrix*vector"} ins(%14, %18 : tensor<1x1x8x1xf32>, tensor<1x1x1x1xf32>) outs(%22 : tensor<1x1x8x1xf32>) -> tensor<1x1x8x1xf32>
  %24 = tensor.collapse_shape %23 [[0, 1, 2, 3]] : tensor<1x1x8x1xf32> into tensor<8xf32>
  %25 = linalg.init_tensor [8] : tensor<8xf32>
  %26 = linalg.generic {indexing_maps = [affine_map<(d0) -> (d0)>, affine_map<(d0) -> (d0)>], iterator_types = ["parallel"]} ins(%24 : tensor<8xf32>) outs(%25 : tensor<8xf32>) {
  ^bb0(%arg3: f32, %arg4: f32):
    linalg.yield %arg3 : f32
  } -> tensor<8xf32>
  %27 = tensor.expand_shape %26 [[0, 1]] : tensor<8xf32> into tensor<8x1xf32>
  %28 = tensor.extract_slice %27[0, 0] [1, 1] [1, 1] : tensor<8x1xf32> to tensor<f32>
  %29 = tensor.expand_shape %28 [] : tensor<f32> into tensor<1x1xf32>
  return %29 : tensor<1x1xf32>
}
```

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

With the introduction of IntegerPolyhedron and IntegerRelation in Presburger
directory, the purpose of FlatAffineConstraints becomes redundant. For users
requiring Presburger arithmetic without IR information, Presburger library can
directly be used. For users requiring IR information,
FlatAffineValueConstraints can be used.

This patch merges FAC and FACV to remove redundancy of FAC.

Reviewed By: arjunp

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

Reviewed By: rafauler

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

Necessary when importing class template specializations that have
simplified template names (may otherwise be necessary - eg: Sony
requires template parameter DIEs even with unsimplified names, but short
of always importing names this is the best I can do for now) - long term
this probably needs a flag for the DICompositeType to specify whether it
needs template parameters on declarations & that flag could power this
behavior, rather than inspecting the name.

Fixes error: invalid conversion from ‘const uint8_t*’ {aka ‘const
unsigned char*’} to ‘uint8_t*’ {aka ‘unsigned char*’}

This reverts commit 3fda0edc, which
breaks crash reproducers in very specific circumstances. Specifically,
since crash reproducers have `UseExternalNames` set to false, the
`File->getFileEntry().getDir()->getName()` call in `DoFrameworkLookup`
would use the *cached* directory name instead of the directory of the
looked-up file.

The plan is to re-commit this patch but to *add*
`ExposesExternalVFSPath` rather than replace `IsVFSMapped`.

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

A missing "break" in the initial implementation had us adding a
spurious "/usr/include" to the header search list. Later someone
introduced LLVM_FALLTHROUGH to prevent a warning.  Replace this with
the correct "break" and make sure the extra directory isn't added to
the PS4 header search list.

This is required for converting function calls such as get_global_id()
into SPIR-V builtins.

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

Mid-air collition of patches.

Fixes error: reinterpret_cast from type ‘const uint8_t*’ {aka ‘const
unsigned char*’} to type ‘char*’ casts away qualifiers

Extend D120185 to also log the node being matched on in case of a crash.
This can help if a matcher is causing a crash or there are not enough interesting nodes bound.

Reviewed By: aaron.ballman

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

This reverts commit 61d67c8e.

This relands commit 6e33e45b.

Fixing the build issue on 32bit machines due to not enough free bits in the PointerUnion.

Change the CreateMemoryInstance interface to take a WritableDataBuffer.

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

Currently, all data buffers are assumed to be writable. This is a
problem on macOS where it's not allowed to load unsigned binaries in
memory as writable. To be more precise, MAP_RESILIENT_CODESIGN and
MAP_RESILIENT_MEDIA need to be set for mapped (unsigned) binaries on our
platform.

Binaries are mapped through FileSystem::CreateDataBuffer which returns a
DataBufferLLVM. The latter is backed by a llvm::WritableMemoryBuffer
because every DataBuffer in LLDB is considered to be writable. In order
to use a read-only llvm::MemoryBuffer I had to split our abstraction
around it.

This patch distinguishes between a DataBuffer (read-only) and
WritableDataBuffer (read-write) and updates LLDB to use the appropriate
one.

rdar://74890607

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

No functionality change.

We currently only launch one set of language clients when starting the extension,
but this has the unfortunate effect of applying the same settings to all workspace
folders. This commit adds support for multiple workspace folders by launching
a server for each folder in the workspace. This allows for having different servers
for different workspace folders, e.g. when there are multiple MLIR projects in
the same workspace.

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

We currently require that server paths are full paths, which is
fairly inconvenient for a myriad of reasons. This commit
attempts to resolve a given server path with the current workspace.

This has a nice additional affect that we can now actually have
default server paths. This means that mlir-lsp-server and
mlir-pdll-lsp-server can be transparently picked up from
build directories (i.e. generally no need for upstream users to
configure the extension).

Fixes #54627

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

Add !isTailCall in isUnconditionalBranch check in order to sync the x86
and aarch64 and fix the fixDoubleJumps pass on aarch64.

Vladislav Khmelevsky,
Advanced Software Technology Lab, Huawei

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

The new -config-file option introduced by 9e1f4f13 was accidentally
referenced as args.config_path on the python side. This patch renames
args.config_path to args.config_file.

To avoid confusion with python file objects, the input argument for
get_tidy_invocation has been renamed from config_path to
config_file_path.

See GitHub issue #54728 for a discussion.

[mlir][linalg] Move linalg.fill folding into linalg.generic pattern from canonicalization to elementwise fusion

Reviewed By: mravishankar

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

This way it can be inlined to its caller. This method
shows up in the profile and it is essentially a fancy
getter. It would benefit from inlining into its callers.

NFC.

The sort should have been lexicographic, but wasn't. This resulted in us
choosing a common symbol at address zero over the intended target function,
leading to a crash.

This patch also moves sorting up to the start of the pass, which means that we
only need to hold on to the canonical symbol at each address rather than a list
of candidates.

In https://reviews.llvm.org/D118972 I increased this buffer to be
big enough to import 261,144 classes but this is a lot more than
we currently have, an allocating a too-large buffer can add memory
pressure even if it's only for a short time.  Reduce the size of
this memory buffer to big enough to import 163,840 classes.  I'll
probably move to a scheme where we read the objc classes in chunks,
with a smaller buffer and multiple inferior function calls.

rdar://91275493

Previously, resolver functions synthesized for target_clones multiversion
functions were not emitted as COMDAT. Now fixed.

The LLVM IR verifier and analysis linter defines and uses several macros in
code that performs validation of IR expectations. Previously, these macros
were named with an 'Assert' prefix. These names were misleading since the
macro definitions are not conditioned on build kind; they are defined
identically in builds that have asserts enabled and those that do not. This
was confusing since an LLVM developer might expect these macros to be
conditionally enabled as 'assert' is. Further confusion was possible since
the LLVM IR verifier is implicitly disabled (in Clang::ConstructJob()) for
builds without asserts enabled, but only for Clang driver invocations; not
for clang -cc1 invocations. This could make it appear that the macros were
not active for builds without asserts enabled, e.g. when investigating
behavior using the Clang driver, and thus lead to surprises when running
tests that exercise the clang -cc1 interface.

This change renames this set of macros as follows:
  Assert -> Check
  AssertDI -> CheckDI
  AssertTBAA -> CheckTBAA