Depends on: D151111

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

Carries out the lowering of the all intrinsic into HLFIR

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

Adds a new HLFIR operation for the ALL intrinsic according to the
design set out in flang/docs/HighLevel.md

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

This is pretty straight forward in the basic form. I did need to move the slideup matching earlier, but that looks generally profitable on it's own.

As follow ups, I plan to explore the v(f)slide1down variants, and see what I can do to canonicalize the shuffle then insert pattern (see _inverse tests at the end of the vslide1up.ll test).

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

At inserting of InterfaceMap, a debug message lacked a newline, so it repeatedly displayed this message within a single line.
Clean up the debug log by inserting a newline at the end of the message.

Reviewed By: rriddle

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

Create SchedWrites, WriteRes for reduction instructions that
are SEW specific. Future patches can use these resources
to customize the behavior of these resources depending on SEW.

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

This fold is buggy if the constant adjustment overflows.
Additionally, since we now canonicalize to min/max intrinsics,
the constants picked here don't actually matter, as long as SPF
still recognizes the pattern.

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

As raised on Issue #62602 - the IceLake scheduler model is still mainly a copy of the SkylakeServer model. This initial commit just fixes the ROB/MicroOpBufferSize to match the size reported on WikiChip/Agner, further fixes to follow in later commits.

Clarify the restrictions on actions that are implied by the implementation as a post-order walk.

Do not replace uses inside the body of `scf.forall` ops with results of the same op.

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

All result handles must be set in case of success.

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

As reported on https://reviews.llvm.org/D150375#4367861 and
following, this change causes PDT invalidation issues. Revert
it and dependent commits.

This reverts commit 0524534d.
This reverts commit ced90d1f.
This reverts commit 9f992cc9.
This reverts commit 1b123204.

We already early-out at the top of the function.

[X86] X86FixupVectorConstantsPass - attempt to replace full width integer vector constant loads with broadcasts on AVX2+ targets

lowerBuildVectorAsBroadcast will not broadcast splat constants in all cases, resulting in a lot of situations where a full width vector load that has failed to fold but is loading splat constant values could use a broadcast load instruction just as cheaply, and save constant pool space.

This patch adds four new tests for upcoming functionality in LLVM:
* complex-deinterleaving-add-mull-fixed-contract.ll
* complex-deinterleaving-add-mull-scalable-contract.ll
* complex-deinterleaving-add-mull-fixed-fast.ll
* complex-deinterleaving-add-mull-scalable-fast.ll.

These tests were generated from the IR of vectorizable loops, which were
compiled from C++ code using different optimization flags in Clang. Each pair
of tests corresponds to Neon and SVE architectures, respectively, and
each pair contains tests compiled with -Ofast and -O3 -ffp-contract=fast
-ffinite-math-only optimization flags.
The tests were stripped of nnan and ninf flags as they have no impact on the
output.
The primary objective of these tests is to show the various sequences of
complex computations that may be encountered and to demonstrate the ability
of ComplexDeinterleaving to support any ordering.

Depends on D147451

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

This patch simply moves the special handling for `linux` files to a
subdirectory. This is done to make it easier in the future to extend
this support to targets (like the GPU) that will have different
dependencies.

Reviewed By: lntue

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

Cleanup suggested in D150991.

Change __tsan_get_report_loc 6th argument 'size' to unsigned long *

Reviewers: vitalybuka, dvyukov

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

Fixes issue introduced by 0f8e0f42 where SimplifyDemandedBits could crash when trying to extract fp data from broadcasted constants

/data/llvm-project/llvm/lib/Transforms/InstCombine/InstructionCombining.cpp:2467:13: error: unused function 'isMustTailCall' [-Werror,-Wunused-function]
static bool isMustTailCall(Value *V) {
            ^
1 error generated.

We try to fold constant computeKnownBits() with context for return
instructions only. Otherwise, we rely on SimplifyDemandedBits() to
fold instructions with constant known bits.

The presence of this special fold for returns is dangerous, because
it makes our tests lie about what works and what doesn't. Tests are
usually written by returning the result we're interested in, but
will go through this separate code path that is not used for anything
else. This patch removes the special fold.

This primarily regresses patterns of the style "assume(x); return x".
The responsibility of handling such patterns lies with passes like
EarlyCSE/GVN anyway, which will do this reliably, and not just for
returns.

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

This results in improved codegen for half/bf16 libcalls on soft ABIs

Adds a RISCVSubtarget helper method for determining if a soft FP ABI is
being targeted (future bf16 related patches make use of this).

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

This moves memintrinsic interceptors (memcpy/memmove/memset) into a new
file sanitizer_common_interceptors_memintrinsics.inc.

This is in preparation of redefining builtins, however, we must be
careful to not redefine builtins in TUs that define interceptors of the
same name.

In all cases except for MSan, memintrinsic interceptors were moved to a
new TU $tool_interceptors_memintrinsics.cpp. In the case of MSan, it
turns out this is not yet necessary (as shown by the later patch
introducing memcpy tests).

NFC.

Reviewed By: vitalybuka

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

With -ftrivial-auto-var-init, do not emit memset() calls for performance
critical stack variables.

Reviewed By: vitalybuka, dvyukov, MaskRay

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

This reverts commit 421a7f81. Dependency
doesn't seem to be necessary and would pull in all of LLVM's codegen
into mlir users that don't require it.

This patch fixes a false negative when the property type
is an objective-c block pointer.

Patch By tripleCC!

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

Resolution of this CWG breaks potential dependency loop between complete-class context of non-static data member initializer (NSDMI), and defaulted default constructor, which is `noexcept` depending on NSDMIs among other things.

For whatever reason in C++11 mode we issue an additional note and a different line number for the primary error. But I find the message itself even worse than aforementioned issues. It describes what's going on, but doesn't say what's bad about it. I find the previous version of this message more clear: https://github.com/llvm/llvm-project/commit/8dbc6b26171167b8ddf66a5f4b6d6fb9baf28336 . Created an issue for that: #62823

Reviewed By: #clang-language-wg, shafik

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

Previous attempt to disable the test didn't seem to work as expected.

The picolib/newlib implementation of scalbn gives slightly different
results compared to glibc and compiler-rt's inlined
__compiler_rt_scalbn in certain rounding modes. Since these tests
are already disabled for msvc which doesn't respect the mode change,
this patch skips them for newlib as well.

Reviewed By: MaskRay

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

Transform operations may indicate that they may accept and consume
several handles pointing to the same or nested payload entities. The
initial implementation of the expensive-checks mode was simply ignoring
such cases as consuming the second handle would fail the check after the
first handle invalidated it by consuming the same payload. Additional
checks had been added since then, which could now trigger assertions in
the expensive-checks module itself (instead of or in addition to
use-after-free assertions down the road), specifically because the
payload associations for invalidated handles is removed from the state
to enable other kinds of checking.

Rework the handling of transform operations with repeated handles so
use-after-consume is still reported properly if the consumption happened
by a preceding operation, as opposed to the a preceding operand of the
same operation that is still (corretly) ignored if the op requests that.

Depends on: D151560

Reviewed By: springerm

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

The implementation and the comment of the AbrrevToUse of VarDecl
looks not consistent with the implementation. This patch refactors it.

[clang][dataflow] Remove unnecessary `ASTContext` parameter from `ControlFlowContext::build` overload.

When introducing this new overload in https://reviews.llvm.org/D151183, I didn't consider that the `ASTContext` parameter was unnecessary because it could also be obtained from the `FunctionDecl`.

Reviewed By: gribozavr2, xazax.hun

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

Add the `llvm.threadlocal.address` intrinsic to the LLVM dialect.

Signed-off-by: Lukas Sommer <lukas.sommer@codeplay.com>

Reviewed By: gysit, zero9178

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