This reverts commit b4abbf17.

GFX11 renamed this instruction to global_atomic_csub_u32 but should
accept the old name as an alias, for consistency with the other global
atomics and with buffer_atomic_csub.

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

First call to Assign is issuing finalization for the
LHS and its components. Avoid calling finalization for components
again when doing the component by component assignment.

Reviewed By: klausler

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

`/clang:-x` emits an error instead of a warning. And if the error is suppressed,
`/clang:-x` takes no effect.
Considering that `/clang:` is a recent addition in 2018-11 and there are MSVC
style alternatives, therefore `/clang:-x` doesn't seem useful and we just reject
it since properly supporting it would add lots of complexity.

Fixes #59307

Reviewed By: MaskRay

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

This reverts commit 735f117f.

Reviewed By: vitalybuka

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

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

At the moment, a large amount of time is spent construction vectors
by pushing back all elements except the first variable. For large
inputs, such as discussed in https://reviews.llvm.org/D135915#4057050
this can result in excessive compile-time.

Instead, it is more efficient to remove the last variable. Then the
original vector can be re-used by simply popping the last element and
then moving the contents to the new system.

This improves time spent in ConstraintElimination for the linked
reproducer from ~43s to ~3s.

This reverts commit 9cffabc6.

Broke windows builds

Also simplified the `-interactive-model-runner-echo-reply` flag to a
bool, because the header will contain the advice spec, so there is an
explicit agreement between the compiler and the host as to what that
should be shaped as.

The current `libcgpu.a` is actually an archive of fatbinaries. The host
file contains nothing but a section called `LLVM_OFFLOADING` that
contains embedded device code. This used to be handled implicitly by
borrowing the OpenMP toolchain, which did this packaging internally.
Passing the OpenMP flags causes problems with trying to move to testing.
This patch pulls this logic out into the CMake and handles it manually.

This patch is a lot of noise, but it fundamentally comes down to the
following changes.
1. Build the source for every GPU architecture (GPU architectures are
   generally not backwards compatible)
2. Combine all of these files into a single binary blob
3. Embed that binary blob into a host file
4. Package these host files into a `.a` archive.
5. The device code will be extracted and managed by the offloading
   linker.

Another important point. Right now we are maintaining an important
distinction with the GPU build. That is, when we build...

Summary:
This was broken, we weren't adding these for the NVPTX tests.

As discussed in [D91000](http://reviews.llvm.org/D91000) with @dyung, the
PlayStation-specific targets are using some custom standard library for
which the current written tests are not appropriate. Even though the
test code defines the `__STDC_LIB_EXT1__` and `__STDC_WANT_LIB_EXT1__`
macros and expected *Annex K.* support, the actual Clang
parser/preprocessor will report these macros as not existing, and thus
fail the tests.

The check reports the **non**-Annex K. functions as suggestions, such as
`fgets()` instead of `gets_s()` to replace `gets()`, so some safe
library suggestions are still there.

This patch is primarily done to unblock the relevant buildbot
[`llvm-clang-x86_64-sie-ubuntu-fast`](http://lab.llvm.org/buildbot/#/builders/139).

This commit partially reverts ed740e74,
as the changes to the "caching logic" was not fixing anything.

Fixes: 60336

Seemingly the concepts sugaring patch caused us to not catch this
situation, which has been confirmed to be a valid error.  Make sure that
we catch this situation in the future, particularly if the concepts
sugaring patch gets re added.

Fill description and fix filename mismatch.

There is a supposedly platform-specific crash related to not recognising
the availability of *Annex K.* properly? This patch is an attempt for
fixing this by moving the reset logic for the cache to a different
place.

It's really a coin-flip at this point whether this is really a fix...

Slly mistake in my first attempt. Hopefully this will do it.

This reverts commit 4a1832a5.
Test fail on (at least) macOS and Windows, see
https://reviews.llvm.org/D142388#4099441

[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