Currently, the example workspace files do not work properly. The
llvm_disable_optional_support_deps option was removed in 7b5d6cd7
and zlib and zstd have been needed-by-default dependencies for a while,
so it would make sense to show definitions in the example bazel
workspace files, especially given the version sensitivity of the zlib-ng
build. This patch removes the use of dated build config flags and adds
dependency definitions to both of the example workspaces.

Reviewed By: aaronmondal

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

When compiling Rust code we sometimes see incomplete debug info leading
to crashes. Narrow the interfaces so we can see where it happens.

Reviewed By: ajwerner

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

This patch applies the semantic checks for executable allocation directives to the new allocators construct.  It also introduces a new check that ensures all items in the list appear in the corresponding Fortran allocate statement.

Reviewed By: kiranchandramohan

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

For character type with unknown length we end up generating
a GEP with the base type `llvm.ptr<i[width]>`. The GEP produces
the address of the first element of the slice, and it should be
using the offset computed in the number of characters, while we were
providing the offset in bytes.

Simple reproducer fails with and w/o HLFIR:
```
program test
  integer,parameter :: ck = 4
  character(:,ck),allocatable :: res(:,:)
  allocate(character(3,ck) :: res(2,2))
  res(1,1) = ck_'111'
  res(1,2) = ck_'222'
  res(2,1) = ck_'333'
  res(2,2) = ck_'444'
  call check(res)
contains
  subroutine check(res)
    character(:,ck),allocatable :: res(:,:)
    print *, res(2,:)
  end subroutine check
end program test
```

Reviewed By: clementval

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

A section of a parameter array may be non-contiguous,
so the current !IsVariable(expr) check is too optimistic
to claim contiguity.

This patch fixes issues with incorrect hlfir.designate op generated
during lowering: the lowering queries IsContiguous to decide whether
to use fir.box<fir.array> or plain fir.ref<fir.array> to represent
the designator result.

Reviewed By: klausler

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

This patch improves the lowering by changing target LLVM intrinsics from
`reduce.fmax` and `reduce.fmin`,
which have different semantic for handling NaN,
to `reduce.fmaximum` and `reduce.fminimum` ones.

Fixes #63969

Depends on D155869

Reviewed By: dcaballe

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

Depends on D141672

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

There were some checks removed previously in
bc196970.

However, all these SPIs are actually defined in macOS 12 and onward, not
macOSX 10.12 as the previous commit would suggest. As a result, if you
have access to these SPIs lldb will fail to compile correctly.

Instead of adding back the __builtin_availability checks, it seems
easier just to check the minimum deployment target with Availability
macros.

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

Add ExtractAPI support C++ classes, fields,  methods, and various qualifiers and specifiers

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

This reverts commit d9b1036b.

Bots are showing breakage.

Correct InstSimplify strictfp tests to follow the rules documented
in the LangRef:
https://llvm.org/docs/LangRef.html#constrained-floating-point-intrinsics

Some of these tests needed the strictfp attribute on function
definitions. After D154991 the constrained intrinsics have the
strictfp attribute by default so they don't need it here, but other
functions do.

Test changes verified with D146845.

These don't really happen with opaque pointers.

Reviewed By: #libc, Mordante

Spies: Mordante, libcxx-commits

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

Correct InstCombine strictfp tests to follow the rules documented
in the LangRef:
https://llvm.org/docs/LangRef.html#constrained-floating-point-intrinsics

Mostly these tests just needed the strictfp attribute on function
definitions. After D154991 the constrained intrinsics have the
strictfp attribute by default so they don't need it here, but other
functions do.

Test changes verified with D146845.

Reviewed By: reames

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

This should fix an error in the Apple CI.

Update adjustRecipesForReductions to directly use the VPlan def-use
chains for in-loop reductions to collect the reduction operations that
need adjusting.

This allows the removal of
 * ReductionChainMap
 * recording of recipes for instruction in the reduction chain
 * removes late uses of getVPValue
 * removes to need for removeVPValueFor.

Reviewed By: Ayal

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

Some places in the format library were identified to benefit from
basic_string's from_range constructor. At that time that constructor was
not implemented. It's implemented now so adjust the code to use this new
constructor.

Reviewed By: #libc, var-const

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

The virtual functions getDefaultNumBlocks and getDefaultNumThreads from the kernels are
only forwarding the call to the generic device's ones. This patch removes those two
functions from the kernels (and their derived ones). Now calls are made to the device's
functions directly.

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

Restructure three code sites that are now eliciting new warnings
from the latest GCC compiler.  One of these looks like a
legitimate problem with a reference to an expression temporary.

Fixes https://github.com/llvm/llvm-project/issues/64200.

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

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

The check was repeated for the fmul and fdiv case, and the caller was
already checking anyway.

The above combine matching m_FNeg to produce a new fneg always would
hide this.

Both LLVM and SPIR-V have some form of "is this float a NaN/Inf"
operation (though LLVM's uses the rather opaque "is.fpclass"
intrinsic), which is not exposed in MLIR.

This has lead to awkward workarounds in -arith-expands-ops where a NaN
test was performed by comparing an operation to itself. This commit
resolves that issue.

Reviewed By: dcaballe, kuhar

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

5ccfa156 removed normalization from abs_path_preserve_drive but I missed adding this case back to the caller

This is failing and/or causing time outs (hard to tell which ) on
our Arm Linux bot:
https://lab.llvm.org/buildbot/#/builders/17/builds/41108

Reviewed By: #libc, Mordante, philnik

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

The starting indices of all vector dimensions are allowed to be out-of-bounds.

E.g.:
```
// %j is allowed to be out-of-bounds (but not %i).
%0 = vector.transfer_read %m[%i, %j] ... {in_bounds = [false]} : memref<?x?xf32>, vector<5xf32>
```

This revision just updates the op documentation and adds extra test cases. Out-of-bounds starting points are already supported by the respective lowerings:
* 2D and higher-dimensional transfers are lowered to 1D transfers by `VectorToScf`. These patterns generate an `scf.if` check for every (potentially unrolled) loop iteration if the dimension is `in_bounds = false`, including the first loop iteration.
- 1D out-of-bounds transfers are lowered to in-bounds transfers by `MaterializeTransferMask`, which adds a mask to the op. The mask is defined by `vector.create_mask (dim-size) - (index)`. In case of an out-of-bounds starting point, the operand of the `vector.create_mask` op is 0 or negative. Negative operands are treated like 0 according to the documentation of `vector.create_mask`.

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

In sorting elements can compare with themselves and sometimes assert
further down the line was triggered.

The changes are somewhat NFC, which explains the lack of test coverage.
libc++ has a debug mode that enables extra precondition checking. When
Clang is built with libc++ in that special mode, a few of Clang's tests
would fail with the libc++ assertion because Clang was not honoring the
preconditions for std::stable_sort. However, Clang would not hit the
precondition failure with any release mode STL, so the changes have no
impact on users beyond ones in this very special circumstance.

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

Temporaries created to store worksharing loop index values were
using different types than that of the original index variables.
This caused invalid IR to be produced when an index variable was
used in binary operations which expected its original type.

Fix this by creating temporaries with the types of their original
variables and converting the loop values, that continue to use
the types that OpenMP runtime expects, to them.

Fixes https://github.com/llvm/llvm-project/issues/60870

Reviewed By: kiranchandramohan

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

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

In 32-bit systems, sizeof(size_t) is 4, so we fail to build an 128-bit
integer in mul_shift_mod_1e9, which ends up ignoring the top bits in the
mantissa.

This patch fixes the issue by calling the Uint constructor directly. If
it's a system that supports 128-bit integers, the constructor that takes
a value will be called, if the system doesn't support 128-bit integers
(like rv32), mantissa is already a UInt.

Reviewed By: lntue, michaelrj

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

When generating snippets for AArch64 with --opcode-index=-1, the code
generator asserts on opcodes that are not supported according to CPU
features.

The same assertion can be triggered even when generating a serial
snippet for a supported opcode if SERIAL_VIA_NON_MEMORY_INSTR execution
mode is used and an unsupported instruction is chosen as the "other
instruction". Unlike the first case, this one may result in flaky
failures because the other instruction is randomly chosen from the
instructions suitable for serializing execution.

This patch adjusts TableGen emitter for *GenInstrInfo.inc to make
possible to query for opcode availability instead of just asserting on
unsupported ones.

~~

Huawei RRI, OS Lab

Reviewed By: courbet

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

As noted on D154130, this was preventing path matching between normalized/unnormalized paths on some windows builds.