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

This adds inline stack frames for symbolizing on Windows.

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

As discussed in https://llvm.discourse.group/t/mlir-support-for-sparse-tensors/2020
this CL is the start of sparse tensor compiler support in MLIR. Starting with a
"dense" kernel expressed in the Linalg dialect together with per-dimension
sparsity annotations on the tensors, the compiler automatically lowers the
kernel to sparse code using the methods described in Fredrik Kjolstad's thesis.

Many details are still TBD. For example, the sparse "bufferization" is purely
done locally since we don't have a global solution for propagating sparsity
yet. Furthermore, code to input and output the sparse tensors is missing.
Nevertheless, with some hand modifications, the generated MLIR can be
easily converted into runnable code already.

Reviewed By: nicolasvasilache, ftynse

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

This should be a perfectly reasonable operation for scalable vectors.
Currently, it only works for zeroinitializer values of
ScalableVectorType, but the fundamental operation is sound and it should
be possible to make it work for other splats

Reviewed By: david-arm

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

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

When doing out-of-tree builds, FIR tests were failing.  I made a change
similar to the one by @jurahul to fix this.

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

As mentioned in https://reviews.llvm.org/D67479#1667256 ,

* `--[no-]allow-shlib-undefined` control the diagnostic for an unresolved symbol in a shared object
* `-z defs/-z undefs` control the diagnostic for an unresolved symbol in a regular object file
* `--unresolved-symbols=` controls both bits.

In addition, make --warn-unresolved-symbols affect --no-allow-shlib-undefined.

This patch makes the behavior match GNU ld.

Reviewed By: psmith

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

Example based on the post-commit comments for D88735.

This patch adds omp_realloc function implementation according to
OpenMP 5.1 specification.

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

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

This is mostly changing stringref to std::string, outs() to cout,
and small supporting changes. This will make running unit tests possible
on systems that are only grabbing the libc part of llvm.

Reviewed By: sivachandra

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

https://rise4fun.com/Alive/I4Ge

  Name: add with pow2 mask
  Pre: isPowerOf2(C2) && (C1 & C2) != 0 && (C1 & (C2-1)) == 0
  %a = add i8 %x, C1
  %r = and i8 %a, C2
  =>
  %n = and i8 %x, C2
  %r = xor i8 %n, C2

We typically use X32 for gnux32 triples

We typically use X32 for gnux32 triples

We typically use X32 for gnux32 triples

We typically use X32 for gnux32 triples

If the variable is implicitly firstprivatized in the inner task-based
region, it also must be firstprivatized in outer task-based regions.
Previously firstprivates were captured in tasks but later it was
optimized to reduce the memory usage. But still need to mark such
variables as implicit firstprivate in outer tasks.

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

Erroring out prevents the library from working with other file formats
(e.g. in embedded). Since that error does not guard us from doing something
incorrect, it seems fine to just remove it.

It is apparently not possible to have two rewrites in one gtest function
because atomic changes in the test harness accumulate.

This allows building on platforms that don't provide that header.

These were previously missing from the SVE lax conversions tests
introduced in this commit:

    23a96b84
    (https://reviews.llvm.org/D91067)

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

Only use X32 for the gnux32 triples in the tests

We typically use X32 for gnux32 triples

Fixes a number of Wshadow warnings.