[flang] Support implicit global external as procedure pointer target

A name that has been used to reference an undeclared global external
procedure should be accepted as the target of a procedure pointer
assignment statement.

Fixes llvm-test-suite/Fortran/gfortran/regression/proc_ptr_45.f90.

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

[flang] Compare component types In AreSameComponent()

The subroutine AreSameComponent() of the predicate AreSameDerivedType()
had a TODO about checking component types that needed completion in order
to properly detect that two specific procedures of a generic are
distinguishable in the llvm-test-suite/Fortran/gfortran/regression
test import7.f90.

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

[llvm-objdump] Use BBEntry::BBID to represent basic block numbers.

Reviewed By: aidengrossman, mtrofin, JestrTulip

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

[libc] Disable 'DecodeInOtherBases` test on GPU targets

This test is excessively slow on GPU targets, taking anywhere beween 5
and 60 seconds to complete each time it's run. See
https://lab.llvm.org/buildbot/#/builders/55/builds/52203/steps/12/logs/stdio
for an example on the NVPTX buildbot. Simply disable testing this on the
GPU for now.

Reviewed By: michaelrj

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

[X86] combineBitcastvxi1 - don't prematurely create PACKSS nodes.

Similar to Issue #63710 - by truncating the v8i16 result with a PACKSS node before type legalization, we fail to make use of various folds that rely on TRUNCATE nodes.

This required tweaks to LowerTruncateVecPackWithSignBits to recognise when the truncation source has been widened and to more closely match combineVectorSignBitsTruncation wrt truncating with PACKSS/PACKUS on AVX512 targets.

One of the last stages before we can finally get rid of combineVectorSignBitsTruncation.

[X86] truncateVectorWithPACK - avoid concat_vectors(extract_subvector(pack()),extract_subvector(pack())) for sub-128 bit vectors

As we start using this after type legalization, we must avoid creating concat_vectors nodes so late.

[AMDGPU] Remove std::optional from VOPD::ComponentProps. NFC.

This class has to be fast and efficient with a trivial copy
constructor.

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

[test] Unsupport CodeGenCXX/destructors for LLVM_ENABLE_REVERSE_ITERATION builds

_ZN5test312_GLOBAL__N_11CD2Ev and _ZN5test312_GLOBAL__N_11DD0Ev are
swapped in LLVM_ENABLE_REVERSE_ITERATION builds. Unsupport for now.

NFC. Move remaining affine/memref test cases into respective dialect dirs

Move a bunch of lingering test cases from test/Transforms/ into
test/Dialect/Affine and MemRef.

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

[X86] Add isUpperSubvectorUndef helper to simplify recognition of vectors widened with undef upper subvectors. NFC.

[Sanitizers][Darwin][Test] Mark symbolize_pc test on Darwin/TSan+UBSan as UNSUPPORTED

Followup to https://reviews.llvm.org/rG760c208f6ff9e97a9a11523c00874a1eec4f876b which XFAIL'd them, but they pass in some configurations.

[flang] Accept an assumed-rank array as operand of ASSOCIATED()

The ASSOCIATED() intrinsic was mistakenly defined in the intrinsic
function table as requiring operands of known rank, which unintentionally
prevented assumed-rank dummy arguments from being tested.

Fixes llvm-test-suite/Fortran/gfortran/regression/pr88932.f90.

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

clang/Debian: add Debian Trixie now that it is in unstable

[MLIR][Linalg] Preserve DPS when decomposing Softmax

Preserve destination passing style (DPS) when decomposing
`linalg.Softmax`; instead of creating a new empty, which may materialize
as a new buffer after bufferization, use the result directly.

Reviewed By: qcolombet

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

[RISCV][NFC] Add RISCVSubtarget field to RISCVExpandPseudo and RISCVPreRAExpandPseudo

To my eye, it's cleaner to just get hold of STI in runOnMachineFunction
(as we do already for InstrInfo) and then accessing the field as needed
rather than to have repeated lookup code in the member functions or
helpers that need it.

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

[libc] Treat the locks array as a bitfield

Currently we keep an internal buffer of device memory that is used to
indicate ownership of a port. Since we only use this as a single bit we
can simply turn this into a bitfield. I did this manually rather than
having a separate type as we need very special handling of the masks
used to interact with the locks.

Reviewed By: JonChesterfield

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

[Support] Implement LLVM_ENABLE_REVERSE_ITERATION for StringMap

ProgrammersManual.html says

> StringMap iteration order, however, is not guaranteed to be deterministic, so any uses which require that should instead use a std::map.

This patch makes -DLLVM_REVERSE_ITERATION=on (currently
-DLLVM_ENABLE_REVERSE_ITERATION=on works as well) shuffle StringMap
iteration order (actually flipping the hash so that elements not in the
same bucket are reversed) to catch violations, similar to D35043 for
DenseMap. This should help change the hash function (e.g., D142862,
D155781).

With a lot of fixes, there are still some violations. This patch
implements the "reverse_iteration" lit feature to skip such tests.
Eventually we should remove this feature.

`ninja check-{llvm,clang,clang-tools}` are clean with
`#define LLVM_ENABLE_REVERSE_ITERATION 1`.

Reviewed By: jhenderson

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

[bazel] update config.h.cmake

[RISCV] Allow delayed decision for ADD/SUB relocations

For a label difference `A-B` in assembly, if A and B are separated by a
linker-relaxable instruction, we should emit a pair of ADD/SUB
relocations (e.g. R_RISCV_ADD32/R_RISCV_SUB32,
R_RISCV_ADD64/R_RISCV_SUB64).

However, the decision is made upfront at parsing time with inadequate
heuristics (`requiresFixup`). As a result, LLVM integrated assembler
incorrectly suppresses R_RISCV_ADD32/R_RISCV_SUB32 for the following
code:
```
// Simplified from a workaround https://android-review.googlesource.com/c/platform/art/+/2619609
// Both end and begin are not defined yet. We decide ADD/SUB relocations upfront and don't know they will be needed.
.4byte end-begin

begin:
  call foo
end:
```

To fix the bug, make two primary changes:

* Delete `requiresFixups` and the overridden emitValueImpl (from D103539).
  This deletion requires accurate evaluateAsAbolute (D153097).
* In MCAssembler::evaluateFixup, call handleAddSubRelocations to emit
  ADD/SUB relocations.

However, there is a remaining issue in
MCExpr.cpp:AttemptToFoldSymbolOffsetDifference. With MCAsmLayout, we may
incorrectly fold A-B even when A and B are separated by a
linker-relaxable instruction. This deficiency is acknowledged (see
D153097), but was previously bypassed by eagerly emitting ADD/SUB using
`requiresFixups`. To address this, we partially reintroduce `canFold` (from
D61584, removed by D103539).

Some expressions (e.g. .size and .fill) need to take the `MCAsmLayout`
code path in AttemptToFoldSymbolOffsetDifference, avoiding relocations
(weird, but matching GNU assembler and needed to match user
expectation). Switch to evaluateKnownAbsolute to leverage the `InSet`
condition.

As a bonus, this change allows for the removal of some relocations for
the FDE `address_range` field in the .eh_frame section.

riscv64-64b-pcrel.s contains the main test.
Add a linker relaxable instruction to dwarf-riscv-relocs.ll to test what
it intends to test.
Merge fixups-relax-diff.ll into fixups-diff.ll.

Reviewed By: kito-cheng

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

Revert "[X86][BF16] Do not scalarize masked load for BF16 when we have BWI"

This reverts commit ca1c05208ed35ba72869c65ad773b2cca4bbd360.

It caused Buildbot fail: https://lab.llvm.org/buildbot#builders/220/builds/24870

[flang][nfc] Clarify the usage of llvmArgs and mlirArgs

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

[X86][BF16] Do not scalarize masked load for BF16 when we have BWI

Fixes #63017

Reviewed By: RKSimon

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

[mlir][nvgpu] Set useDefaultAttributePrinterParser

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

Revert "[mlir][spirv] Add D155747 to `.git-blame-ignore-revs`"

This reverts commit b8a20658fee019fe9126a29f930ddd5dedec51ff.

This does not preserve the line history of cut-and-pasted code like I
expected.

[ARM] Extend regression test for D154281

Add a test case with a larger call frame which does not satisfy
ARMFrameLowering::hasReservedCallFrame.

[FunctionAttrs] Add tests for PR63936 (NFC)

Add missing SLEEF mappings to scalable vector functions for log2 and log2f

In the original commit adding SLEEF mappings, https://reviews.llvm.org/D146839
mappings for log2/log2f were missing.

Reviewed By: paulwalker-arm

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

[ValueTracking] Check non-zero operator before dominating condition (NFC)

Prefer checking for non-zero operator before non-zero via
dominating conditions. This is to make sure we don't have
compile-time regressions when special cases that are currently
part of isKnownNonZero() get moved into isKnownNonZeroFromOperator().

[DAG] SimplifyDemandedBits - call ComputeKnownBits for constant non-uniform ISD::SRL shift amounts

We only attempted to determine KnownBits for uniform constant shift amounts, but ComputeKnownBits is able to handle some non-uniform cases as well that we can use as a fallback.

[mlir][linalg] MapCopyToThreadsOp: Support tensor.pad

Also return the generated loop op.

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

[ValueTracking] Extract isKnownNonZeroFromOperator() (NFC)

Split off the primary part of the isKnownNonZero() implementation,
in the same way it is done for computeKnownBits(). This makes it
easier to reorder different parts of isKnownNonZero().

Revert "[TLI][AArch64] Add missing SLEEF mappings to scalable vector functions for log2 and log2f"

This reverts commit 791c89600aaa288d7066aea95a1e06cd6d61b2e3.

[TLI][AArch64] Add missing SLEEF mappings to scalable vector functions for log2 and log2f

In the original commit adding SLEEF mappings, https://reviews.llvm.org/D146839
mappings for log2/log2f were missing.

Reviewed By: paulwalker-arm

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

[mlir][linalg] BufferizeToAllocationOp: Add option to materialize buffers for operands

Add an option that does not bufferize the targeted op itself, but just materializes a buffer for the destination operands. This is useful for partial bufferization of complex ops such as `scf.forall`, which need special handling (and an analysis if the region).

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

[mlir][transform] Add `apply_cse` option to `transform.apply_patterns` op

Applying the canonicalizer and CSE in an interleaved fashion is useful after bufferization (and maybe other transforms) to fold away self copies.

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

[clang][analyzer]Fix non-effective taint sanitation

There was a bug in alpha.security.taint.TaintPropagation checker
in Clang Static Analyzer.
Taint filtering could only sanitize const arguments.
After this patch, taint filtering is effective also
on non-const parameters.

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

[Clang] Diagnose jumps into statement expressions

Such jumps are not allowed by GCC and allowing them
can lead to situations where we jumps into unevaluated
statements.

Fixes #63682

Reviewed By: aaron.ballman, #clang-language-wg

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

[mlir][nvgpu] Ignore -Wunused-function in NVGPUDialect.cpp (NFC)

In file included from /Users/jiefu/llvm-project/mlir/lib/Dialect/NVGPU/IR/NVGPUDialect.cpp:363:
/Users/jiefu/llvm-project/build-Release/tools/mlir/include/mlir/Dialect/NVGPU/IR/NVGPUAttrDefs.cpp.inc:22:36: error: unused function 'generatedAttributeParser' [-Werror,-Wunused-function]
static ::mlir::OptionalParseResult generatedAttributeParser(::mlir::AsmParser &parser, ::llvm::StringRef *mnemonic, ::mlir::Type type, ::mlir::Attribute &value) {
                                   ^
/Users/jiefu/llvm-project/build-Release/tools/mlir/include/mlir/Dialect/NVGPU/IR/NVGPUAttrDefs.cpp.inc:46:30: error: unused function 'generatedAttributePrinter' [-Werror,-Wunused-function]
static ::mlir::LogicalResult generatedAttributePrinter(::mlir::Attribute def, ::mlir::AsmPrinter &printer) {
                             ^
2 errors generated.

[llvm][SLP] Exit early if inputs to comparator are equal

**TL;DR:** This PR modifies a comparator. The comparator is used in a subsequent call to llvm::stable_sort. Sorting comparators should follow strict weak ordering - in particular, (x < x) should return false. This PR adds a fix to avoid an infinite loop when the inputs to the comparator are equal.

**Details**:

Sometimes when two equivalent tensors passed into the comparator, we encounter infinite looping (at https://github.com/llvm/llvm-project/blob/aae2eaae2cefd3132059925c4592276defdb1faa/llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp#L4049)

Although it seems like this comparator will never be called with two equivalent pointers, some sanitizers, e.g. https://chromium.googlesource.com/chromiumos/third_party/gcc/+/refs/heads/stabilize-zako-5712.88.B/libstdc++-v3/include/bits/stl_algo.h#360, will add checks for (x < x). When this sanitizer is used with the current implementation, it triggers a comparator check for (x < x) which runs into the infinite loop

Reviewed By: ABataev

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

[clangd] Prefer definitions for gototype and implementation

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

[X86] matchBinaryShuffle - match PACKUS for v2i64 -> v4i32 shuffle truncation patterns.

Handle PACKUSWD on +SSE41 targets, or fallback to PACKUSBW on any +SSE2 target

[X86] Add packus.ll test coverage

Similar to the existing packss.ll tests

[X86] packss.ll - add SSE4.2 test coverage

[OpenMP][OMPT] Add 'Initialized' flag

We observed some overhead and unnecessary debug output.
This can be alleviated by (re-)introduction of a boolean that indicates, if the
OMPT initialization has been performed.

Reviewed By: jdoerfert

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

[clangd] Make the order of missing-include edits deterministic

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

Mark this test as unsupported on Windows systems

There is a strange issue happening with command line processing though. The
command line argument
   --export-dynamic-symbol 'f*'
does not have the single quotes stripped on some Windows targets (but not
all). This causes the glob matching to fail, which means the test fails on
some Windows bots and passes on others.

This is expected to be a temporary measure to get bots back to green. I've not
found a commit that has caused a behavioral change that could be reverted
instead, so this could be an issue with lit or test machine configuration.

[bazel] Tweak dependency spaghetti after 70c2e0618a0f3c09ed7149d88b4987b932eb6705

[bazel] Port 5d8813dec69360fce897f063a4a65106ae8ea22b

[mlir] Fix build after D155680

[mlir] Update bazel build after rG70c2e0618a0f3c09ed7149d88b4987b932eb6705

[Clang] Fix access to an unitinialized variable

This fixes the spurious test failure introduced in f9caa12328b2

Revert "[LIT] Added an option to llvm-lit to emit the necessary test coverage data, divided per test case"

This reverts commit d8e26bccb3016d255298b7db78fe8bf05dd880b2.
Test case are meant to run only when LLVM_INDIVIDUAL_TEST_COVERAGE is set.

[OpenMP] [OMPT] [6/8] Added callback support for target data operations, target submit, and target regions.

This patch adds support for invoking target callbacks but does not yet
invoke them. A new structure OmptInterface has been added that tracks
thread local states including correlation ids. This structure defines
methods that will be called from the device independent target library
with information related to a target entry point for which a callback
is invoked. These methods in turn use the callback functions maintained
by OmptDeviceCallbacksTy to invoke the tool supplied callbacks.

Depends on D124652

Patch from John Mellor-Crummey <johnmc@rice.edu>
With contributions from:
Dhruva Chakrabarti <Dhruva.Chakrabarti@amd.com>

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

[mlir][bufferization] Remove cleanup pipeline from bufferization pass

To keep the pass simple, users should apply cleanup passes manually when necessary. In particular, `-cse -canonicalize` are often desireable to fold away self-copies that are created by the bufferization.

This addresses a comment in D120191.

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

[AMDGPU] [NFC] Fixed a typo in SIShrinkInstructions.cpp

Reviewed By: pravinjagtap

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

[AMDGPU][RFC] Update isLegalAddressingMode for GFX9 SMEM signed offsets

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

[AMDGPU] Add tests for SMEM addressing modes in CodeGenPrepare

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

[LIT] Added an option to llvm-lit to emit the necessary test coverage data, divided per test case

This patch is the first part of https://llvm.org/OpenProjects.html#llvm_patch_coverage.

We have first define a new variable LLVM_TEST_COVERAGE which when set, pass --emit-coverage option to
llvm-lit which will help in setting a unique value to LLVM_PROFILE_FILE for each RUN. So for example
coverage data for test case llvm/test/Analysis/AliasSet/memtransfer.ll will be emitted as
build/test/Analysis/AliasSet/memtransfer.profraw

Reviewed By: hnrklssn

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

[mlir][transform][structured][python] Allow str arg in match_op_names.

Allow the `names` argument in `MatchOp.match_op_names` to be of type
`str` in addition to `Sequence[str]`. In this case, the argument is
treated as a list with one name, i.e., it is possible to write
`MatchOp.match_op_names(..., "test.dummy")` instead of
`MatchOp.match_op_names(..., ["test.dummy"])`.

Reviewed By: ftynse

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

[mlir][linalg][transform] Extend diagnostics of FuseIntoContainingOp.

This patch extends the diagnostic output of `FuseIntoContainingOp` when
it fails to find the next producer by also provided the location of the
affected transform op.

Reviewed By: ftynse

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

[mlir][nvgpu] Add `tma.create.descriptor` to create tensor map descriptor

The Op creates a tensor map descriptor object representing tiled memory region. The descriptor is used by Tensor Memory Access (TMA). The `tensor` is the source tensor to be tiled. The `boxDimensions` is the size of the tiled memory region in each dimension.

The pattern here lowers `tma.create.descriptor` to a runtime function call that eventually calls calls CUDA Driver's `cuTensorMapEncodeTiled`. For more information see below:
https://docs.nvidia.com/cuda/cuda-driver-api/group__CUDA__TENSOR__MEMORY.html

Depends on D155453

Reviewed By: nicolasvasilache

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

[RISCV] Add SDNode patterns for vrol.[vv,vx] and vror.[vv,vx,vi]

These correspond to ROTL/ROTR nodes

Reviewed By: craig.topper

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

[mlir][test] Add missing LIT config for `mlir-cpu-config` + emulator

Similarly to when using `lli`, make sure that when using
`mlir-cpu-runner` with an emulator, a full path to `mlir-cpu-runner` is
used. Otherwise `mlir-cpu-runner` won't be found and you will get the
following error:
```
Error while loading mlir-cpu-runner: No such file or directory
```

This patch should fix:
  * https://lab.llvm.org/buildbot/#/builders/179
The breakage was originally introduced in
https://reviews.llvm.org/D155405.

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

[mlir] allow region branch spec from parent op to itself

RegionBranchOpInterface did not allow the operation with regions to
specify itself as successors. Therefore, this implied that the control
is always transferred to a region before being transferred back to the
parent op. Since the region can only transfer the control back to the
parent op from a terminator, this transitively implied that the first
block of any region with a RegionBranchOpInterface is always executed
until the terminator can transfer the control flow back. This is
trivially false for any conditional-like operation that may or may not
execute the region, as well as for loop-like operations that may not
execute the body.

Remove the restriction from the interface description and update the
only transform that relied on it.

See
https://discourse.llvm.org/t/rfc-region-control-flow-interfaces-should-encode-region-not-executed-correctly/72103.

Depends On: https://reviews.llvm.org/D155757

Reviewed By: Mogball, springerm

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

[mlir] allow dense dataflow to customize call and region operations

Initial implementations of dense dataflow analyses feature special cases
for operations that have region- or call-based control flow by
leveraging the corresponding interfaces. This is not necessarily
sufficient as these operations may influence the dataflow state by
themselves as well we through the control flow. For example,
`linalg.generic` and similar operations have region-based control flow
and their proper memory effects, so any memory-related analyses such as
last-writer require processing `linalg.generic` directly instead of, or
in addition to, the region-based flow.

Provide hooks to customize the processing of operations with region-
cand call-based contol flow in forward and backward dense dataflow
analysis. These hooks are trigerred when control flow is transferred
between the "main" operation, i.e. the call or the region owner, and
another region. Such an apporach allows the analyses to update the
lattice before and/or after the regions. In the `linalg.generic`
example, the reads from memory are interpreted as happening before the
body region and the writes to memory are interpreted as happening after
the body region. Using these hooks in generic analysis may require
introducing additional interfaces, but for now assume that the specific
analysis have spceial cases for the (rare) operaitons with call- and
region-based control flow that need additional processing.

Reviewed By: Mogball, phisiart

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

[RISCV] Remove VPatBinaryExtVL_WV_WX multiclass. NFC

It's no longer needed now that the sext/zext patterns have been merged.

Reviewed By: craig.topper

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

[RISCV] Add patterns for vnsr[a,l].wx where shift amount has different type than vector element

We're currently only matching scalar shift amounts where the type is the same
as the vector element type. But because only the bottom log2(2*SEW) bits are
used, only 7 bits will be used at most so we can use any scalar type >= i8.

This patch adds patterns for the case above, as well as for when the shift
amount type is the same as the widened element type and doesn't need extended.

Reviewed By: craig.topper

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

[RISCV] Add tests for vnsr[l,a].wx patterns that could be matched

These patterns of ([l,a]shr v, ([s,z]ext splat)) only pick up the cases where
the scalar has the same type as the vector element. However since only the low
log2(SEW) bits of the scalar are read, we could use any scalar type that has
been extended.

Reviewed By: craig.topper

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

[SystemZ] Allow symbols in immediate asm operands

Currently mentioning any symbols in immediate asm operands is not
supported, for example:

    error: invalid operand for instruction
    lghi %r4,foo_end-foo

The immediate problem is that is*Imm() and print*Operand() functions do
not accept MCExprs, but simply relaxing these checks is not enough:
after symbol addresses are computed, range checks need to run against
resolved values.

Add a number of SystemZ::FixupKind members for each kind of immediate
value and process them in SystemZMCAsmBackend::applyFixup(). Only
perform the range checks, do not change anything.

Adjust the tests: move previously failing cases like the one shown
above out of insn-bad.s.

Reviewed By: uweigand

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

[mlir] Fix bazel build after b96bd025b35761ae181da7e1796708c46e59f5d5

[Clang] Fix constraint checking of non-generic lambdas.

A lambda call operator can be a templated entity -
and therefore have constraints while not being a function template

   template<class T> void f() {
     []() requires false { }();
   }

In that case, we would check the constraints of the call operator
which is non-viable. However, we would find a viable candidate:
the conversion operator to function pointer, and use it to
perform a surrogate call.
These constraints were not checked because:
 * We never check the constraints of surrogate functions
 * The lambda conversion operator has non constraints.

From the wording, it is not clear what the intent is but
it seems reasonable to expect the constraints of the lambda conversion
operator to be checked and it is consistent with GCC and MSVC.

This patch also improve the diagnostics for constraint failure
on surrogate calls.

Fixes #63181

Reviewed By: #clang-language-wg, aaron.ballman

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

[X86] Expand constant expressions in test (NFC)

[mlir][nvgpu] Improve finding module Op to for `mbarrier.create`

Current transformation expects module op to be two level higher, however, it is not always the case. This work searches module op in a while loop.

Reviewed By: nicolasvasilache

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

[mlir][nvgpu] Add nvgpu.tma.async.load and nvgpu.tma.descriptor

This work adds `nvgpu.tma.async.load` Op that requests tma load asyncronusly using mbarrier object.

It also creates nvgpu.tma.descriptor type. The type is supposed be created by `cuTensorMapEncodeTiled` cuda drivers api.

Reviewed By: nicolasvasilache

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

[mlir] remove RegionBranchOpInterface from linalg ops

Linalg structure ops do not implement control flow in the way expected
by RegionBranchOpInterface, and the interface implementation isn't
actually used anywhere. The presence of this interface without correct
implementation is confusing for, e.g., dataflow analyses.

Reviewed By: springerm

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

[LoopIdiom] Regenerate test checks (NFC)

[InstCombine] Regenerate test checks (NFC)

Reapply [IR] Mark and constant expressions as undesirable

Reapply after fixing an issue in canonicalizeLogicFirst() exposed
by this change (218f97578b26f7a89f7f8ed0748c31ef0181f80a).

-----

In preparation for removing support for and expressions, mark them
as undesirable. As such, we will no longer implicitly create such
expressions, but they still exist.

[bazel] add missing dep for llvm/unittests:frontend_tests

[IR] Accept non-Instruction in BinaryOperator::CreateWithCopiedFlags() (NFC)

The underlying copyIRFlags() API accepts arbitrary values and can
work with flags on operators (i.e. instructions or constant
expressions). Remove the arbitrary limitation that the
CreateWithCopiedFlags() API imposes, so we can directly pass through
values matched by PatternMatch, which can be constant expressions.

The attached test case works fine now, but would crash with an
upcoming change to not produce and constant expressions.

[AArch64] Basic vector bswap costs

This adds some basic vector bswap costs, providing the type is supported.

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

[NFC] Remove needless nullchecks.

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

[llvm-exegesis] Guard `__builtin_thread_pointer` behind a configure check

Due to arguably a bug in GCC[0], using `__has_builtin` is not sufficient to check whether `__builtin_thread_pointer` can actually be compiled by GCC. This makes it impossible to compile LLVM with `llvm-exegesis` enabled with e.g. GCC 10 as it does have the builtin, but no implementation for architectures such as x86.

This patch works around this issue by making it a cmake configure check whether the builtin can be compiled and used, rather than relying on the broken preprocessor macro.

[0] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96952, demonstration: https://godbolt.org/z/9z5nWM6Ef

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

[mlir] Add opt-in default property bytecode read and write implementation

Using properties currently requires at the very least implementing four methods/code snippets:
* `convertToAttribute`
* `convertFromAttribute`
* `writeToMlirBytecode`
* `readFromMlirBytecode`

This makes replacing attributes with properties harder than it has to be: Attributes by default do not require immediately defining custom bytecode encoding.

This patch therefore adds opt-in implementations of `writeToMlirBytecode` and `readFromMlirBytecode` that work with the default implementations of `convertToAttribute` and `convertFromAttribute`. They are provided by `defvar`s in `OpBase.td` and can be used by adding:
```
let writeToMlirBytecode = writeMlirBytecodeWithConvertToAttribute;
let readFromMlirBytecode = readMlirBytecodeUsingConvertFromAttribute;
```
to ones TableGen definition.

While this bytecode encoding is almost certainly not ideal for a given property, it allows more incremental use of properties and getting something sane working before optimizing the bytecode format.

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

[gn build] Port c3648f37d0ed

[libc++][hardening] Don't trigger uncategorized assertions in the hardened mode.

The hardened mode is intended to only include security-critical,
relatively low-overhead checks that are intended to be usable in
production. By default, assertions are excluded from this mode.

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

[libc++][ranges] Implement `ranges::to`.

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

[modularize] Stabilize iteration order when processing module maps

Many diagnostics (e.g., ProblemsDuplicate.modularize,
ProblemsDisplayLists.modularize) are dependent on the iteration order of
StringMap, which is not guaranteed to be deterministic
(https://llvm.org/docs/ProgrammersManual.html#llvm-adt-stringmap-h).
clang::ModuleMap::Modules is a StringMap. For now, sort by name in
modularize.

Sarif: stabilize artifacts order

StringMap iteration order is not guaranteed to be deterministic
(https://llvm.org/docs/ProgrammersManual.html#llvm-adt-stringmap-h).

[Driver] -fopenmp-targets=: stabilize OrderedOffloadingToolchains value order

to make actions deterministic.
StringSet iteration order is not guaranteed to be deterministic
(https://llvm.org/docs/ProgrammersManual.html#llvm-adt-stringmap-h).

[lldb] Fix -Wreturn-type in RegisterInfos_x86_64_with_base_shared.cpp (NFC)

/data/llvm-project/lldb/source/Plugins/Process/Utility/RegisterInfos_x86_64_with_base_shared.cpp:319:1: error: non-void function does
not return a value in all control paths [-Werror,-Wreturn-type]
}
^
1 error generated.

[RISCV] precommit for removing useless copy from undef subreg

testcase from https://github.com/llvm/llvm-project/issues/63554

Reviewed By: kito-cheng

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

[clang] fix for D155342

[clang][JumpDiagnostics] ignore non-asm goto target scopes

The current behavior of JumpScopeChecker::VerifyIndirectOrAsmJumps was
to cross validate the scope of every jumping statement (goto, asm goto)
against the scope of every label (even if the label was not even a
possible target of the asm goto).

When we have multiple asm goto's with unique targets, we could trigger
false positive build errors complaining that labels that weren't even in
the asm goto's label list could not be jumped to.  Example:

    error: cannot jump from this asm goto statement to one of its possible targets
    asm goto(""::::foo);
    note: possible target of asm goto statement
    bar:
    ^

Fixes: https://github.com/ClangBuiltLinux/linux/issues/1886

Reviewed By: void, jyu2, rjmccall

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

[llvm][utils] Use literal type name for non-template data formatters (NFC)

These don't need to be regex.

[lldb] Delete unused LibcxxOptionalSummaryProvider (NFC)

No longer needed following refactoring in D115178.

[lldb] Identify Swift-implemented ObjC classes

Classes implemented in Swift can be exposed to ObjC. For those classes, the ObjC
metadata is incomplete. Specifically, the encoded types of the ivars are incomplete. As
one might expect, the Swift metadata _is_ complete. In such cases, the Swift runtime
should be consulted when determining the dynamic type of a value.

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

[BOLT] Improve Linux Kernel ORC reader

  * Sort ORC entries in the internal table. Older Linux kernels did not
    sort them in the file (only during boot time).
  * Add an option to dump sorted ORC tables (--dump-orc).
  * Associate entries in the internal ORC table with a BinaryFunction
    even when we are not changing the function.
  * If the function doesn't have ORC entry at the start, propagate ORC
    state from a previous entry.

Reviewed By: Amir

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

[llvm-profdata] Stabilize iteration order for InstrProfWriter

If two functions are inserted to the same bucket, their order in the
serialized profile is dependent on StringMap iteration order, which is
not guaranteed to be deterministic.
(https://llvm.org/docs/ProgrammersManual.html#llvm-adt-stringmap-h).
Use a sort like we do in writeText.

[libc++][hardening][NFC] Rename `HardenedMode.rst` to `Hardening.rst`.

This addresses a comment from https://reviews.llvm.org/D154997.