Some clients treat this as compilation error.

Performance by core-math (core-math/glibc 2.31/current llvm-14):
28.879/20.843/20.15

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

Performance by core-math (core-math/glibc 2.31/current llvm-14):
10.845/43.174/13.467

The review is done on top of D132809.

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

1) `double log2_eval(double)` function added with better than float precision is added.
2) Some refactoring done to put all auxiliary functions and corresponding data
to one place to reuse the code.
3) Added tests for new functions.
4) Performance and precision tests of the function shows, that it more precise than exiting log2,
(no exceptional cases), but timing is ~5% higer that on current one.

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

This patch makes parsing dense arrays with type elision work properly.
If a ranked tensor type is supplied to `parseAttribute` on a dense
array, the element type is skipped. Moreover, if type elision is set to
`AttrTypeElision::Must`, the element type is elided.

For example, this allows

```
memref.global @z : memref<3xi32> = array<1, 2, 3>
```

Fixes #57433

Depends on D132758

Reviewed By: rriddle

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

This patch turns `DenseArrayBaseAttr` into a fully-functional attribute by
adding a generic parser and printer, supporting bool or integer and floating
point element types with bitwidths divisible by 8. It has been renamed
to `DenseArrayAttr`. The patch maintains the specialized subclasses,
e.g. `DenseI32ArrayAttr`, which remain the preferred API for accessing
elements in C++.

This allows `DenseArrayAttr` to hold signed and unsigned integer elements:

```
array<si8: -128, 127>
array<ui8: 255>
```

"Exotic" floating point elements:

```
array<bf16: 1.2, 3.4>
```

And integers of other bitwidths:

```
array<i24: 8388607>
```

Reviewed By: rriddle, lattner

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

This reverts commit 2be8af8f.

This updates the ExecutorSharedMemoryMapperService::deinitialize and
InProcessMemoryMapper::deinitialize methods to deinitialize in reverse order,
bringing them into alignment with the behavior of
InProcessMemoryManager::deallocate and SimpleExecutorMemoryManager::deallocate.
Reverse deinitialization is required because later allocations can depend on
earlier ones.

This fixes failures in the ORC runtime test suite.

There is an implicit i64 cast due to the << during MulOp's folder.

Reviewed By: NatashaKnk

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

The patch introduces the required changes to update the pass declarations and definitions to use the new autogenerated files and allow dropping the old infrastructure.

Reviewed By: mehdi_amini, rriddle

Differential Review: https://reviews.llvm.org/D132838

When we use selective instrumentation and instrument a file
that is not in the selected files list provided via -fprofile-list,
we generate an empty raw profile. This leads to empty_raw_profile
error when we try to read that profile. This patch fixes the issue by
generating a raw profile that contains only a profile header when
there are no counters and profile data.

A small reproducer for the above issue:
echo "src:other.cc" > code.list
clang++ -O2 -fprofile-instr-generate -fcoverage-mapping
-fprofile-list=code.list code.cc -o code
./code
llvm-profdata show default.profraw

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

We know the type is 32 or 64 bits, we can use getZExtValue and
bypass the slow path check in APInt.

The code was changed with:
9eb2c011
...but missed the corresponding code comment.

The pointer operands for the ScatterVectorize node may contain
non-instruction values and they are not checked for "already being
vectorized". Need to check that such pointers are already vectorized and
gather them instead of trying to build vectorize node to avoid compiler
crash.

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

We can use srliw to shift out the trailing bits and slli to shift
back in zeros. The sign extend of srliw will 0 the upper 32 bits
since we will be shifting a 0 into bit 31.

If a kernel has uneven dimensions we can have a value of workitem-id-x
divided by the wavefrontsize non-uniform. For example dimensions (65, 2)
will have workitems with address (64, 0) and (0, 1) packed into a same
wave which gives 1 and 0 after the division by 64 respectively.

Unfortunately, this limits the optimization to OpenCL only and only if
reqd_work_group_size attribute is set. This patch limits it to 1D kernels,
although that shall be possible to perform this optimization is the size
of the X dimension is a power of 2, we just do not currently have
infrastructure to query it.

Note that presence of amdgpu-no-workitem-id-y attribute does not help
as it only hints the lack of the workitem-id-y query, but not the absence
of the actual 2nd dimension, therefore affecting just the SGPR allocation.

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

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

Reviewed By: shafik

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

This instruction was referring to the wrong VOPProfile, likely due to a
typo, leading to an incorrect destination register type.

The MC layer will care about this change, but is NFC while 16-bit values
actually use 32 bit registers.

Reviewed By: foad

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

Sometimes in the AST we can have an ArraySubscriptExpr,
where the index is an ArrayInitIndexExpr.
ArrayInitIndexExpr is not a constant, so
ProBoundsConstantArrayIndexCheck reports a warning when
it sees such expression. This expression can only be
implicitly generated, and always appears inside an
ArrayInitLoopExpr, so we shouldn't report a warning.

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

InstSimplify does this via isKnownNonEqual(), so it's already
using knownbits on these patterns and trying other folds.

The following patch (https://reviews.llvm.org/D129051) broke z/OS builds by renaming the parameter name. This patch accounts for that change.

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

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

Because of D128669, CPY is being used to zero active lanes even in the case of -0.0f. This patch checks for floating point positive zero. That way SVEDup0 won't match -0.0f.

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

Reviewed By: paulwalker-arm

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

[mlir] Async: add unrealized cast materializations to AsyncToLLVM pass

Reviewed By: ftynse

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

We recently removed the singleton dimension level type (see the revision
https://reviews.llvm.org/D131002) since it was unimplemented but also
incomplete (properties were missing). This revision add singleton back as
extra dimension level type, together with properties ordered/not-ordered
and unique/not-unique. Even though still not lowered to actual code, this
provides a complete way of defining many more sparse storage schemes (in
the long run, we want to support even dimension level types and properties
using the additional extensions proposed in [Chou]).

Note that the current solution of using suffixes for the properties is not
ideal, but keeps the extension relatively simple with respect to parsing and
printing. Furthermore, it is rather consistent with the TACO implementation
which uses things like Compressed-Unique as well. Nevertheless, we probably
want to separate dimension level types from properties when we add more types
and properties.

Reviewed By: Peiming

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

Doh! This clearly slipped my review. Thanks DuckDuckGo for showing me
the error of my ways :).

This document describes the basic usage and implementation details for
HLSL entry functions in Clang.

Reviewed By: python3kgae

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

Previously, depending on how you constructed a UUID from data or a
StringRef, an input value of all zeros was valid (e.g. setFromData)
or not (e.g. setFromOptionalData).  Since there was no way to tell
which interpretation to use, it was done somewhat inconsistently.
This standardizes the meaning of a UUID of all zeros to Not Valid,
and removes all the Optional methods and their uses, as well as the
static factories that supported them.

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

This test is an expected failure on AMDGPU. The expected failure is a GPU memory
failure, which will typically result in the device totally failing. This isn't
an issue for some GPU configurations that do not use the offloading device to
also drive the display server. However, if the main GPU is used for testing it
will reliably result in the user's display becoming unresponsive. This makes it
difficult to run the GPU offloading tests on many systems.

This patch simply makes this test unsupported so it no longer runs and freezes
my computer when using `ninja check-openmp`.

Reviewed By: tianshilei1992

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

When checking parameter packs for expansion, instead of basing the diagnostic for
length mismatch for outer parameters only on the known number of expansions,
we should also analyze SubstTemplateTypeParmPackType and SubstNonTypeTemplateParmPackExpr
for unexpanded packs, so we can emit a diagnostic pointing to a concrete
outer parameter.

Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>

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

Fixes using the signed ceildiv op instead of incorrectly assuming positive loop bounds.
Adjusts the tests for above.

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

Uses arith.divui where it is safe to do so.
Adjusts the tests for above.

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

arith-overflow.ll and update tests accordingly.

- These two tests stands out when data layout is explicitly added in a
  sweep study (D132889)

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

The phrasal verb is spelled "set up"; "setup" is a noun.

Suggested in https://reviews.llvm.org/D132947#inline-1280089

Amends test Transforms/LoopSimplify/update_latch_md2.ll
with auto-generated checks.

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

Guard a debug message with LLVM_DEBUG

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

This was mentioned in review D131326.

Reviewed By: var-const, #libc, philnik

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