Add the atomic subroutine, atomic_fetch_or, to the list of
intrinsic subroutines. Add new enumerators to deal with the rank
of the atom dummy argument, and the kind of atomic_int_kind. Use
check for a coindexed-object for the fourth dummy argument. Move
atomic_int_kind and atomic_logical_kind definitions from
iso_fortran_env module to the __fortran_builtins module to allow
for access to those values when analyzing `atomic_fetch_or`
calls in flang/lib/Evaluate/intrinsics.cpp.

Reviewed By: jeanPerier

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

Expose [[ https://github.com/llvm/llvm-project/blob/main/mlir/lib/Dialect/Affine/Utils/Utils.cpp#L661 | Dialect/Affine/Utils/Utils.cpp#hasNoInterveningEffect ]] for downstream use (particular use case is a lazy implementation of [[ https://github.com/llvm/llvm-project/blob/main/mlir/lib/Dialect/Affine/Utils/Utils.cpp#L845 | forwardStoreToLoad ]] in CIRCT). This exposes hasNoInterveningEffect and instantiates for the necessary types.

Reviewed By: bondhugula

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

The phase ordering test is the almost unoptimized IR for the example
in issue #42100; it was passed through -mem2reg to reduce obvious
excessive load/store and other noise.

D134879

This patch teaches the module inliner a traversal order designed for
the instrumentation FDO (+ThinLTO) scenario.

The new traversal order prioritizes call sites in the following order:

1. Those call sites that are expected to reduce the caller size

2. Those call sites that have gone through the cost-benefit analaysis

3. The remaining call sites

With this fairly simple traversal order, a large internel benchmark
yields performance comparable to the bottom-up inliner -- both in
terms of the execution performance and .text* sizes.

Big thanks goes to Liqiang Tao for the module inliner infrastructure.

I still have hacks outside this patch to prevent excessively long
compilation or .text* size explosion.  I'm trying to come up with
acceptable solutions in near future.

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

We should catch more issues this way.

This previously the behavior and was dropped in cde5e5b6.

Reviewed By: hans

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

Tested with `ninja check-flang`

Noticed this while working on D133326. Let's see whehter all compilers
now support this feature.

Reviewed By: #libc, philnik, ldionne

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

Suggested by @lattner in https://discourse.llvm.org/t/rfc-define-precise-arith-semantics/65507/22.

Tested with:
`ninja check-mlir check-mlir-integration check-mlir-mlir-spirv-cpu-runner check-mlir-mlir-vulkan-runner check-mlir-examples`

and `bazel build --config=generic_clang @llvm-project//mlir:all`.

Reviewed By: lattner, Mogball, rriddle, jpienaar, mehdi_amini

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

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

When checking the RHS of fdiv, we should set the SignBitOnly flag,
because a negative zero can become -Inf, which is ordered less
than zero.

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

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

This patch updates llvm/utils/llvm-original-di-preservation.py to create more
compact HTML verify-debuginfo-preserve reports by:
- removing duplicated debug info bugs,
- introducing -compress option to create highly compressed report.
Additionally, this patch makes script able to process very large JSON inputs.
That is done by reading & analyzing JSON report in chunks.

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

Debugify in OriginalDebugInfo mode (verify-each-debuginfo-preserve), when used
in parallel builds of large projects, can produce incorrect report. More
precisely, simultaneous writes to JSON report file, could form incorrect JSON
objects, which describe found Debug Info bugs.
This patch uses the lock/unlock mechanism to protect JSON report file and also
makes script llvm/utils/llvm-original-di-preservation.py resilient to corrupted
lines in the report file. So, it ensures the creation of HTML report.

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

This change updates the costs to make constant pool loads match their actual cost, and adds the broadcast special case to avoid too many regressions. We really need more information about the constants being rematerialized, but this is an incremental improvement.

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

This will allow to model (variadic) reductions with this special op instead of
using GenericOp.

RFC: https://discourse.llvm.org/t/rfc-primitive-ops-add-mapop-reductionop-transposeop-broadcastop-to-linalg/64184

Reviewed By: craig.topper

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

There are lots of options interacting in complex ways here, and when moving to
`getDefaultUnwindTableLevel` I had refactored this and changed behaviour in
some cases. So this reverts the basic structure of the logic back to the
original, while leaving the hook in the new style.

The helper function in GPUFuncOp incorrectly assumed the workgroup
attribution attribute is always present. Instead, treat its absence as
if its value was zero, i.e., no workgroup attributions are specified.

Closes #58045.

Reviewed By: nicolasvasilache

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

Functions that implement expansion of response and config files depend
on many options, which are passes as arguments. Extending the expansion
requires new options, it in turn causes changing calls in various places
making them even more bulky.

This change introduces a class ExpansionContext, which represents set of
options that control the expansion. Its methods implements expansion of
responce files including config files. It makes extending the expansion
easier.

No functional changes.

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

The previous version of the patch would incorrect convert an
existing argmemonly attribute into an inaccessiblemem_or_argmemonly
attribute.

-----

This updates checkFunctionMemoryAccess() to infer a precise
FunctionModRefBehavior, rather than an approximation split into
read/write and argmemonly.

Afterwards, we still map this back to imprecise function attributes.
This still allows us to infer some cases that we previously did not
handle, namely inaccessiblememonly and inaccessiblemem_or_argmemonly.
In practice, this means we get better memory attributes in the
presence of intrinsics like @llvm.assume.

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

Test for the issue reported in https://reviews.llvm.org/D134527#3821010.

This reverts commit c0902959.

One of the test cases fails. Revert this until I know a way to make it
work reliably.

This patch disables split-complex.ll for aarch64-pc-windows-msvc.
split-complex.ll fails with a crash when run on AArch64/Windows.
I have reported following issue: llvm-project/issues/58053

The -fallow-half-arguments-and-returns option was removed in
59528e4bdb27ed4ab3, replaced with an always-on target option under
AArch64/Arm. There are two tests - fp16-sema.c and renderscripts.rs that
test that an error is produced for __fp16 function args/returns, which
are now expected to pass for Arm/AArch64. i.e they no longer give the
same error as before on native Arm/AArch64 machines. Alter the targets
of those tests to compensate.

Reviewed By: ftynse

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

Rename some interface methods to be consistent with the new accessor names.
This is a preparation for adding a ReduceOp, which then will implement
getIteratorTypes() and getOutputs() instead of iterator_types() and outputs().

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

We can use another if constexpr here to make this shorter and easier to
understand.

It's used in the bytecode dump of the function itself, so useful to
identify which function is being called.

Just use a constexpr if here instead of two different implementations.
[#

Follow up to https://reviews.llvm.org/D133934