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

For (X op Y) op Z --> (Y op Z) op X
we can still do transform when Y is multi-use. In D131356 limit it to one-use,
this patch remove this limit.

This is still not a complete solution, I add a todo test to show it.
In this case, X and Y are both multi use, we can't differentiate how to convert based on this.
But at least we don't make the code worse，and it can solve half the scenarios.

Reviewed By: kda, kstoimenov

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

IIUC, the conversion part is not part of atomic operations and fences should be put around converted atomic operations.
This also fixes atomic load of floating point values which requires fence on PowerPC.

Reviewed By: efriedma

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

This reverts commit 33162a81.

This change breaks the usage of module maps with modules disabled, such
as for layering checking via `-fmodules-decluse`.

Regression test added.

[Clang] Fix lambda CheckForDefaultedFunction(...) so that it checks the CXXMethodDecl is a special member function before attempting to call DefineDefaultedFunction(...)

In Sema::CheckCompletedCXXClass(...) It used a lambda CheckForDefaultedFunction
the CXXMethodDecl passed to CheckForDefaultedFunction may not be a special
member function and so before attempting to apply functions that only apply to
special member functions it needs to check. It fails to do this before calling
DefineDefaultedFunction(...). This PR adds that check and test to verify we no
longer crash.

This fixes https://github.com/llvm/llvm-project/issues/57431

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

`getCPUStr()` fallsback to `getMCPU()`.

The only difference between `getCPUStr()` and `getMCPU()` is that
`getCPUStr()` handles `-mcpu=native`. That doesn't matter for this case.

This is just a simplification of the original code and it does not
change the functionality. So no new tests added.

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

The llvm-jitlink tool is not needed by other sanitizer tests.

Some code previous needed the `used` attribute to prevent the GCC
compiler versions 5 and 6 from removing it. This is no longer required
as the minimum supported GCC version for LLVM 16 is >=7.1.0.

Reviewed By: JonChesterfield, vzakhari

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

Reviewed By: whisperity

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

An upcoming patch to LLDB will require the ability to decode base64. This patch adds support for decoding base64 and adds tests.

Resubmission of https://reviews.llvm.org/D126254 with where decodeBase64Byte is no longer a lambda but a static function. Some compilers have different errors or warnings with respect to what needs to be captured and what doesn't (see comments in https://reviews.llvm.org/D126254 for details).

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

Failing on some bots, reverting until I can fix it.

This reverts commit f80a0ea7.

The provided testcase would previously fail with an assertion due to later down below trying to allocate registers for `token` return types and arguments. This is especially problematic as the process would then exit instead of falling back to using FastIsel.

This patch fixes that by simply explicitly failing translation if either of these intrinsics are encountered.

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

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

Instead of trying to "fix" the original driver invocation by appending
arguments to it, split it into multiple commands, and for each -cc1
command use a CompilerInvocation to give precise control over the
invocation.

This change should make it easier to (in the future) canonicalize the
command-line (e.g. to improve hits in something like ccache), apply
optimizations, or start supporting multi-arch builds, which would
require different modules for each arch.

In the long run it may make sense to treat the TU commands as a
dependency graph, each with their own dependencies on modules or earlier
TU commands, but for now they are simply a list that is executed in
order, and the dependencies are simply duplicated. Since we currently
only support single-arch builds, there is no parallelism available in
the execution.

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

The Darwin module has specified [no_undeclared_includes] for at least five years now, there's no need to hard code it in the compiler.

Reviewed By: ributzka, Bigcheese

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

The test case is about pmull2 instruction generated used than a SIMD
ldr being generated. So aarch64-pmull2.ll is a better test file.

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

The previous implementation would still crash if the element type was
not iterable. This patch changes SparseElementsAttr to properly
implement `try_value_begin_impl` according to ElementsAttr and changes
DenseElementsAttr to implement `tryGetValues` as the basis for querying
element values.

Depends on D132904

Reviewed By: rriddle

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

This patch changes `value_begin_impl` to a faillable
`try_value_begin_impl` so that specific cases can fail iteration if the
type doesn't match the internal storage.

Reviewed By: rriddle

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

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

Fix two small issues in the live-memory variant of ObjectContainerMachOFileset.

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

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