This reverts commit 65fd17c2.

It breaks LLD/MachO tests that seems use obj2yaml the check the output.

Support more instructions in SpeculativeExecution pass:
- ExtractElement
- InsertElement
- ShuffleVector

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

The protocol is based on the spec found here:
https://microsoft.github.io/language-server-protocol/specifications/specification-3-16/#textDocument_prepareCallHierarchy

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

When we produce an YAML output, we also print leading zeroes currently.
An output might look like this:

```
- Name:    .dynsym
  Type:    SHT_DYNSYM
  Address: 0x0000000000001000
  EntSize: 0x0000000000000018
```

There are probably no reason to print leading zeroes.
It just makes harder to read values. This patch stops printing them.
The output becomes like:

```
- Name:    .dynsym
  Type:    SHT_DYNSYM
  Address: 0x1000
  EntSize: 0x18
```

This affects obj2yaml mostly, but also dsymutil and llvm-xray tools output.

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

add whitespace

Pin some legacy PM specific RUN lines to legacy PM.

- Add `mlirElementsAttrGetType` C API.
- Add `def_buffer` binding to PyDenseElementsAttribute.
- Implement the protocol to access the buffer.

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

We can use GF2P8AFFINEQB to reverse bits in a byte. Shuffles are needed to reverse the bytes in elements larger than i8. LegalizeVectorOps takes care of inserting the shuffle for the larger element size.

We already have Custom lowering for v16i8 with SSSE3, v32i8 with AVX, and v64i8 with AVX512BW.

I think we might be able to use this for scalars too by moving into a vector and back. But I'll save that for a follow up as its a little more involved.

Reviewed By: RKSimon, pengfei

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

This tests legacy PM specific stuff.

This type supports a calibrated type with min, max provided.

This will be used for importing calibration values of intermediate tensors (e.g. LSTM) which can't be imported with QuantStats op.

This type was initially suggested in the following RFC: https://llvm.discourse.group/t/rfc-a-proposal-for-implementing-quantization-transformations-in-mlir/655

Reviewed By: stellaraccident

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

This was previously explored in reviews.llvm.org/D69094.

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

* I had missed the note about "Standard size" in the docs. On Windows, the 'l' types are 32bit.
* This fixes the only failing MLIR-Python test on Windows.

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

Factor out `SmallVectorImple::insert_one_impl`, a common implementation
for `insert(iterator, T&&)` and `insert(iterator, T const&)`. This is
just a clean up and has no functionality change.

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

I don't see any reason not to unconditionally retrieve TLI, it's fairly
cheap.

Fixes calls-errno.ll under NPM.

Reviewed By: asbirlea

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

These changes cause substantial binary size increases for non-opt builds.
For example, the visit.pass.cpp test grows from 20k to 420k.

Further work will be done to re-land this patch without the size increases,
but that work is proving too tricky to fix forward.

This patch fully reverts:

* 35d22691

And it partially reverts:

* bb43a0cd

The latter of which added XFAIL's to new variant tests
because the new implementation needlessly makes non-throwing code
paths in variant invoke throwing code.

This means the reverted change also breaks source backwards compat
with code compiled on OS X targeting older system dylibs. There is no
need for this to be the case. We should fix it before recommitting.

Reviewed as:
https://reviews.llvm.org/D91662

The design of the PreservedCFG Checker (landed with the commit
28012e00) has a fundamental flaw which makes it incorrect.
The checker is based on the PreservedAnalyses result returned
by functional passes: if CFGAnalyses is in the returned
PreservedAnalyses set, then the checker asserts that the CFG
snapshot saved before the pass is equal to the CFG snapshot
taken after the the pass. The problem is in passes that change
CFG and invalidate CFGAnalyses on their own. Such passes do not
return CFGanalyses in the returned PreservedAnalyses. So the
checker mistakenly expects CFG unchanged. As an example see the
class TestSimplifyCFGInvalidatingAnalysisPass in the new tests.

It is interesting that the bug was not found in LLVM. That is
because the CFG checker ran only if CFGAnalyses was checked
incorrectly:
  if (!PassPA.allAnalysesInSetPreserved<CFGAnalyses>())
    return;

but must be checked as follows:
  auto PAC = PA.getChecker<PreservedCFGCheckerAnalysis>();
  if (!(PAC.preserved() ||
        PAC.preservedSet<AllAnalysesOn<Function>>() ||
        PAC.preservedSet<CFGAnalyses>())
    return;

A fully redesigned checker will be sent as a separate follow-up
patch.

Reviewed By: Serguei Katkov, Jakub Kuderski

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

Revert "Revert "Revert "[analyzer] NFC: Move path diagnostic consumer implementations to libAnalysis."""

This reverts commit 41bcc05e.

This reverts commit 77bb3ebe.

This patch adds support for creating Guard Address-Taken IAT Entry Tables (.giats$y sections) in object files, matching the behavior of MSVC. These contain lists of address-taken imported functions, which are used by the linker to create the final GIATS table.
Additionally, if any DLLs are delay-loaded, the linker must look through the .giats tables and add the respective load thunks of address-taken imports to the GFIDS table, as these are also valid call targets.

Reviewed By: rnk

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

On some platform (like WebAssembly), alignof(mlir::AttributeStorage) is 4 instead of 8. As a result, it makes the program crashes since PointerLikeTypeTraits<mlir::Attribute>::NumLowBitsAvailable is 3.

So I explicitly set the alignment of mlir::AttributeStoarge to 64 bits, and set PointerLikeTypeTraits<mlir::Attribute>::NumLowBitsAvailable according to it.

I also fixed an another related error (alignof(NamedAttribute) -> alignof(DictionaryAttributeStorage)) based on reviewer's comments.

Reviewed By: dblaikie, rriddle

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

As with precompiled headers, it's useful for indexers to be able to
continue through compiler errors in dependent modules.

Resolves rdar://69816264

Reviewed By: akyrtzi

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

This reverts commit b7926ce6.

Going with a simpler approach.

This reverts commit 0b11d018.

Going with a simpler approach.

When polly is enabled and LLVM_BYE_LINK_INTO_TOOLS=ON is on, ExtensionDependencies.inc does not compile.

$ ninja tools/llvm-config/CMakeFiles/llvm-config.dir/llvm-config.cpp.o
tools/llvm-config/ExtensionDependencies.inc:8:1: error: excess elements in struct initializer
{{"Bye", {"Bye",nullptr}}},

ExtensionDependencies.inc pre-patch:
  std::array<ExtensionDescriptor, 2> AvailableExtensions{
  {{"Polly", {"support", "core", ...,nullptr}}},
  {{"Bye", {"Bye",nullptr}}},
  };

ExtensionDependencies.inc with this patch:
  std::array<ExtensionDescriptor, 2> AvailableExtensions{
  ExtensionDescriptor{"Polly", {"support", "core", ...,nullptr}},
  ExtensionDescriptor{"Bye", {"Bye",nullptr}},
  };

Reviewed By: Meinersbur

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

gn generates improper compile_commands.json files by not escaping
backslashes.

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

This is a more full featured version of ``--allow-undefined``.
The semantics of the different methods are as follows:

report-all:

   Report all unresolved symbols.  This is the default.  Normally the
   linker will generate an error message for each reported unresolved
   symbol but the option ``--warn-unresolved-symbols`` can change this
   to a warning.

ignore-all:

   Resolve all undefined symbols to zero.  For data and function
   addresses this is trivial.  For direct function calls, the linker
   will generate a trapping stub function in place of the undefined
   function.

import-functions:

   Generate WebAssembly imports for any undefined functions.  Undefined
   data symbols are resolved to zero as in `ignore-all`.  This
   corresponds to the legacy ``--allow-undefined`` flag.

The plan is to followup with a new mode called `import-dynamic` which
allows for statically linked binaries to refer to both data and
functions symbols from the embedder.

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

This reverts commit 662ed9e6.

CMake's find_package(Python3) and find_package(Python2) packages have a PYTHON_EXECUTABLE, Python2_EXECUTABLE, and Python3_EXECUTABLE cmake variables which control which version of python is built against.  As far as I can tell, the rest of LLVM honors these variables. This can cause the build process to fail when  if the automatically selected version of Python can't run due to modifications of LD_LIBRARY_PATH when using spack.  The corresponding Spack issue is https://github.com/spack/spack/issues/19908.  The corresponding LLVM issue is 48180

I believe an appropriate fix is to add the variables to the list of PASSTHROUGH_VARIABLES in cmake/Modules/AddCompilerRT.cmake, and this fixed compilation errors for me.

This bug affects distributions like Gentoo and package managers like Spack which allow for combinatorial versioning.

Reviewed By: Meinersbur

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

The rounding behavior of NormalFloat to float format has been changed
to round to nearest. Also, a bug in NormalFloat to subnormal number
conversion has been fixed.

Reviewed By: lntue

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

We used to produce a bogus warning if the width couldn't be represented
in 32 bits, and assert if it couldn't be represented in 64 bits.

The tests don't specify a triple in some cases, since they shouldn't be
necessary, so I've updated the tests to detect via macro when they are
running on win32 to give the slightly altered diagnostic.

As noticed in D91470, some of the functions of LLVMFrontend, are not tested within the library itself (but indirectly by its users clang and flang). In particular, the file OMP.cpp which is generated by tablegen was not tested at all.

Add tests for the parsing helpers in OMP.cpp. These are not meant to be exhaustive tests, just to ensure that we have some basic tests for all API functions.

Reviewed By: clementval

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