[X86] canonicalizeShuffleWithBinOps - all merging shuffles with INSERT_SUBVECTOR as well as generic target shuffles.

We can probably expand this to more faux shuffles as time goes on.

0a51bc73 added a new API to libclang
but forgot to bump the minor version number.

There is no reasonable way to test this change, hence the lack of test
coverage.

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

Add cost for extending to illegal scalable vector types.
Add testing file for the extend operations.

Reviewed By: sdesmalen

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

Checks for unsafe functions, mostly those listed in the
SEI CERT C Coding Standard Recommendation `MSC24-C` and Rule `MSC33-C`.

For the listed functions, an alternative, more secure replacement is
suggested, if such is available. The checker heavily relies on the
functions from "Annex K" (Bounds-checking interfaces) from C11, but
there are several other recommendations not directly from Annex K.

Differential Revision: http://reviews.llvm.org/D91000



Reviewed-By: aaron.ballman, dkrupp, steakhal, whisperity

Co-Authored-By: Tamás Koller <koller.tamas1996@gmail.com>
Co-Authored-By: Balázs Benics <balazs.benics@sigmatechnology.se>
Co-Authored-By: Whisperity <whisperity@gmail.com>

Pulled out of Issue #60441 - we really need that handling in the middle-end, but there's some obvious DAG cleanups we can try as well

Currently evaluating an expression involving a global variable inside
an inline namespace will fail to lookup said variable. This is because
the `SymbolFileDWARF::FindGlobalVariables` discards from consideration
all DIEs whose decl_context doesn't exactly match that of the lookup.

This patch relaxes this restriction by checking whether C++ rules
would permit the lookup. This is permitted by the DWARFv5 spec in
chapter `3.2.2 Namespace Entries`:
```
A namespace may have a DW_AT_export_symbols attribute which is a flag
which indicates that all member names defined within the namespace may be
referenced as if they were defined within the containing namespace.
```

The motivation for this is evaluating `std::ranges` expressions, which
heavily rely on global variables inside inline namespaces. E.g.,
`std::views::all(...)` is just an invocation of the `operator()`
on `std::ranges::views::__cpo::all`.

**Testing**

* Added API tests

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

Fixes API tests for older compilers.
Since https://reviews.llvm.org/D141828 defaulted
arguments will be omitted, but older Clang's won't.

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

LLVM_ENABLE_PER_TARGET_RUNTIME_DIR is set in llvm/CMakeLists.txt
and in llvm/runtimes/CMakeLists.txt.

This meant that anything you passed down, or any platform not using
this layout yet would have it enabled despite it being OFF earlier.

To fix this, check if we have already defined the variable
and if so, use that value.

bultin_register_target I don't fully understand the purpose of.
So for now I have left it setting the value to ON. The rest will
respect what was previously set.

Reviewed By: MaskRay

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

The LoopVectorizer emits the (scaled) element count as i32, which for
scalable VFs results in calls to @llvm.vscale.i32(). This value is scaled
and further zero-extended to i64.

The zero-extend can be folded away by executing the whole expression in i64
type using @llvm.vscale.i64(). Any logical `and` that would needed to mask
the result can be further folded away by KnownBits analysis when
vscale_range is set.

Reviewed By: nikic

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

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

[FLANG][MLIR] Update all module symbol references after changing FuncOp symbol during external name mangling

This fixes an issue where the symbols for operations that were not directly
handled by the rewriting in ExternalNameConversion.cpp were not updated
accurately when a FuncOp symbol was modified. Resulting in a name
mismatch between the FuncOp and the operation holding a symbol to
the FuncOp.

This fix works by updating all of the symbols relating to a FuncOp in a
module, this did not show up as an issue previously as fir::CallOps were
getting specific handling and only fir::CallOps were being tested. So
as the more larger case is now being handled the specific handling for
fir::CallOps has been removed (but is still handled by the fix).

Reviewers:
clementval

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

Currently TargetTransformInfo::getPredictableBranchThreshold() method
returns hardcoded value 99. This value affects the decision whether to
convert select instruction to branch or not in several passes:
SelectOptimize, CodeGenPrepare, SimplifyCFG.

It would be useful to make possible to play with that threshold in order
to test select-optimize heuristics.

Option was originally introduced in the TargetLoweringBase, but was
removed in the revision 664d0c05 and not restored in the TTI

Patch Author: aleksandr.popov
Reviewed By: spatel
Differential Revision: https://reviews.llvm.org/D143060

This addresses part of https://github.com/llvm/llvm-project/issues/60079

The test for external functions was not considering function templates.

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

Prior to this patch it was possible to use the dim operation on a 0-D
memref/tensor.
Unless we want to change the semantic of a 0-D shape, this doesn't make
sense because, paraphrasing the dim op semantic, this is guaranteed to
produce something that is undefined. (The requested index is guaranteed
to be equal to or greater than the rank.)

Harden the type requirements for the dim op by disallowing 0-D shaped
types.

This "fixes" llvm.org/PR60195 by rejecting dim op on 0-D shapes instead of
crashing during LLVM conversion.

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

There were missing checks in the aligned region code, copy-paste errors
(= usage of the IsReachedFromAlignedBarrierOnly value instead of
IsReachingAlignedBarrierOnly value on the forward pass), and a missing
update of the call state for sync declarations and definitions.

Partially fixes https://github.com/llvm/llvm-project/issues/60425

Before we might have ended up queriying the AAExecutionDomain of a
different function, which resulted in wrong optimistic results.

Partially fixes https://github.com/llvm/llvm-project/issues/60425

The test was checking that we can print an error message when a variable
is optimized away, but the optimizer got smarter (D140404) in tracking
the variable's value (so that we were not able to recover its value).

Using a value in an argument registers (argc) makes it more likely to be
overwritten by subsequent function calls (and permanently lost).

If a chain of two selects share a true/false value and are controlled
by two setcc nodes, that are never both true, we can fold away one of
the selects. So, the following:
(select (setcc X, const0, eq), Y,
  (select (setcc X, const1, eq), Z, Y))

Can be combined to:
  select (setcc X, const1, eq) Z, Y

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

gcc warned like
 ../../lld/ELF/InputSection.cpp:75:37: warning: ISO C++11 requires at least one argument for the "..." in a variadic macro
    75 |     invokeELFT(parseCompressedHeader);
       |                                     ^

The rank from the allocate object might be different from the rank
from the mold expression. Use the rank from the allocate object
when applying to mold so the bounds can be set correctly.

Reviewed By: jeanPerier

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

Reviewed By: pengfei, skan

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

The LLVM now supports v0.11 of the RVV intrinsics. Users can use the macro
`riscv_v_intrinsic` to distinguish what kind of intrinsics is supported in
the compiler.

Please refer to tag descriptions under

https://github.com/riscv-non-isa/rvv-intrinsic-doc/tags

Reviewed By: kito-cheng, asb

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

Warn when a lambda specifies a default capture and captures
``this``. Offer FixIts to correct the code.

Reviewed By: njames93, carlosgalvezp

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

gcc warned about
 ../../clang/lib/Sema/AnalysisBasedWarnings.cpp:2187:23: warning: unused variable 'FC' [-Wunused-variable]
  2187 |       if (const auto *FC = dyn_cast<CallExpr>(Operation)) {
       |                       ^~

Handle !noundef metadata in comhineMetadata. The behavior of violating
!noundef metadata is undefined behavior. So if K dominates J, we can
preserve it uncontionally, otherwise, we preserve it if both K and J
have !noundef metadata been set.

This patch also makes !noundef metadata added in KnownIDs when doing
instruction combine for phi node or global value numbering for loads.

Reviewed By: nikic

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

Use the exact addressing mode information instead of the default to
make better use of offsets in instructions.

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

Reviewed By: shchenz, amyk

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

Change signature of TargetLowering::getRoundingControlRegisters so that
it returns ArrayRef, not plain pointer.

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

I missed byte swapping the size field.

Reviewed By: xen0n, MaskRay

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

According to the [[ https://loongson.github.io/LoongArch-Documentation/LoongArch-toolchain-conventions-EN.html | LoongArch Toolchain Conventions ]]
it is possible to specify the ABI modifier (the "D" part of "LP64D")
via the environment field in the target triple. This is needed for
proper support for Debian-style multiarch tuples as well, so add triple
awareness to `LoongArchSubtarget` via addition of
`LoongArchABI::computeTargetABI`. Let the explicit `--target-abi`
argument intuitively take precedence over the triple-implied ABI.

Reviewed By: SixWeining

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

This patch also sets `UNSUPPORTED` on some tests which need `mcjit` and
`emulated tls` support.

Depends on D142950

Reviewed By: lhames

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