We already assert that the given PC is in range and that the
function has a body, so the SrcMap should generally never be empty.
However, when generating destructors, we create quite a few instructions
for which we have no source information, which may cause the previous
assertion to fail. Return the end of the source map in this case.

Extra tests for https://github.com/llvm/llvm-project/pull/94610.

This PR is to add validation to the test case with
get_image_array_size/get_image_dim calls
(transcoding/check_ro_qualifier.ll). This test case didn't pass
validation because of invalid emission of OpCompositeExtract instruction
(Result Type must be the same type as Composite.).

In order to fix the problem this PR improves type inference in general
and partially addresses issues:
* https://github.com/llvm/llvm-project/issues/91998
* https://github.com/llvm/llvm-project/issues/91997

A reproducer from the description of the latter issue is added as a new
test case as a part of this PR.

Oryon is an ARM V8 AArch64 CPU from Qualcomm.

---------

Co-authored-by: Wei Zhao <wezhao@qti.qualcomm.com>

Create a new class and file for functions that update GDB index.

Extend the folding ability of the RewriteAsConstant patterns to include
tensor.pad operations on constants. The new pattern with constant fold
tensor.pad operations which operate on tensor constants and have
statically resolvable padding sizes/values.

    %init = arith.constant dense<[[6, 7], [8, 9]]> : tensor<2x2xi32>
    %pad_value = arith.constant 0 : i32

    %0 = tensor.pad %init low[1, 1] high[1, 1] {
      ^bb0(%arg1: index, %arg2: index):
        tensor.yield %pad_value : i32
    } : tensor<2x2xi32> to tensor<4x4xi32>

becomes

    %cst = arith.constant dense<[[0, 0, 0, 0],
                                 [0, 6, 7, 0],
                                 [0, 8, 9, 0],
                                 [0, 0, 0, 0]]> : tensor<4x4xi32>

Co-authored-by: Spenser Bauman <sabauma@fastmail>

`unmerge_i64` and `unmerge_i32` were exactly the same test cases. This
PR would fix that, so `unmerge_i32` would actually unmerge a 32 bit
value into two 16 bit values.

PR #75125 introduced upward propagation of some OMPT-related CMake
variables.
For stand-alone builds this results in a warning that `SCOPE_PARENT` has
no meaning in a top-level directory.

Co-authored-by: Marianne Mailhot-Sarrasin <marianne.mailhot-sarrasin@octasic.com>

/llvm-project/llvm/lib/Target/NVPTX/NVVMIntrRange.cpp:33:12:
error: private field 'SmVersion' is not used [-Werror,-Wunused-private-field]
  unsigned SmVersion;
           ^
1 error generated.

Adds an AArch64-specific version of isLSRCostLess, changing the relative
importance of the various terms from the formulae being evaluated.

This has been split out from my vscale-aware LSR work, see the RFC for
reference:
https://discourse.llvm.org/t/rfc-vscale-aware-loopstrengthreduce/77131

Revamp the NVVMIntrRange pass making the following updates:
- Use range attributes over range metadata. This is what instcombine has
move to for ranges on intrinsics in
https://github.com/llvm/llvm-project/pull/88776 and it seems a bit
cleaner.
- Consider the `!"maxntid{x,y,z}"` and `!"reqntid{x,y,z}"` function
metadata when adding ranges for `tid` srge instrinsics. This can allow
for smaller ranges and more optimization.
- When range attributes are already present, use the intersection of the
old and new range. This complements the metadata change by allowing
ranges to be shrunk when an intrinsic is in a function which is inlined
into a kernel with metadata. While we don't call this more then once
yet, we should consider adding a second call after inlining, once this
has had a chance to soak for a while and no issues have arisen.

I've also re-enabled this pass in the TM, it was disabled years ago due
to "numerical discrepancies" https://reviews.llvm.org/D96166. In our
testing we haven't seen any issues with adding ranges to intrinsics, and
I cannot find any further info about what issues were encountered.

Summary:
This reverts commit 574ab7e7.

IceLakeServer/SkylakeServer can only use Port01 for the FADD/FSUB stage

Confirmed with uops.info + Agner

IceLakeServer was copying these from SkylakeServer, but integer HADD/SUB can now run on an extra port

Summary:
Currently, we register images into a linear table according to the
logical OpenMP device identifier. We then initialize all of these images
as one block. This logic requires that images are compatible with *all*
devices instead of just the one that it can run on. This prevents us
from running on systems with heterogeneous devices (i.e. image 1 runs on
device 0 image 0 runs on device 1).

This patch reworks the logic by instead making the compatibility check a
per-device query. We then scan every device to see if it's compatible
and do it as they come.

This fixes compile time regression after #93692.

This will be used for a new CI job that runs the static analyzer.

The test case is adapted from llvm/test/CodeGen/RISCV/fp16-promote.ll,
because it covers some more IR patterns that ought to be common.

Fixes #93894

Test cases inspired by
https://github.com/llvm/llvm-project/issues/90417.

There were a handlful of scope flags that were not handled in the dump
function, which would then lead to an assert.

Derived type components may use a given `Symbol` regardless of what
parent objects they are a part of. Because of that, simply using a
symbol address is not sufficient to determine object identity.

Make the designator a part of the IdTy. To compare identities, when
symbols are equal (and non-null), compare the designators.

Noticed while working on #94601

The conversion between _Float16 and long double will crash clang-11 on
aarch64. This is fixed in clang-12: https://godbolt.org/z/8ceT9454c

clangAnalysis is already being pulled in via
clang_target_link_libraries(). Also listing it in LINK_LIBS means that
we'll link both against the static libraries and the shared
libclang-cpp.so library if CLANG_LINK_CLANG_DYLIB is enabled, and waste
time on unnecessary LTO.

VPT blocks that do not produce an interesting 'output' (like a stored
value or reduction result), do not need to be predicated on vctp for the
whole loop to be tail-predicated. Just producing results for the valid
tail predication lanes should be enough.

/llvm-project/llvm/lib/Transforms/IPO/ExpandVariadics.cpp:426:14:
error: unused variable 'OriginalFunctionIsDeclaration' [-Werror,-Wunused-variable]
  const bool OriginalFunctionIsDeclaration = OriginalFunction->isDeclaration();
             ^
/llvm-project/llvm/lib/Transforms/IPO/ExpandVariadics.cpp:445:13:
error: unused variable 'VariadicWrapperDefine' [-Werror,-Wunused-variable]
  Function *VariadicWrapperDefine =
            ^
2 errors generated.

Remove some #includes in ExpandVariadics.cpp as it will cause layering
violations.

We need them for scalable address calculation and
legal scalable addressing modes.

Adds a calling convention for calls to the `__arm_get_current_vg`
support
routine, which preserves X1-X15, X19-X29, SP, Z0-Z31 & P0-P15.

See https://github.com/ARM-software/abi-aa/pull/263

Revert "Reapply "[Clang][CWG1815] Support lifetime extension of temporary created by aggregate initialization using a default member initializer" (#92527)" (#94600)

Reverting due to
https://github.com/llvm/llvm-project/pull/92527#issuecomment-2149120420.

This reverts commit f049d72a

.

Co-authored-by: Bogdan Graur <bgraur@google.com>

This reverts commit 97c866f6.

This fails on 32bit machines. See
https://github.com/llvm/llvm-project/pull/92083

Revert "[Analyzer][CFG] Correctly handle rebuilt default arg and default init expression (#91879)" (#94597)

This depends on https://github.com/llvm/llvm-project/pull/92527 which
needs to be reverted due to
https://github.com/llvm/llvm-project/pull/92527#issuecomment-2149120420.

This reverts commit 905b402a

.

Co-authored-by: Bogdan Graur <bgraur@google.com>

This is a mostly-target-independent variadic function optimisation and
lowering pass. It is only enabled for AMDGPU in this initial commit.

The purpose is to make C style variadic functions a zero cost
abstraction. They are lowered to equivalent IR which is then amenable to
other optimisations. This is inherently slightly target specific but
much less so than one might expect - the C varargs interface heavily
constrains the ABI design divergence.

The pass is primarily tested from webassembly. This is because wasm has
a straightforward variadic lowering strategy which coincides exactly
with what this pass transforms code into and a struct passing convention
with few cases to check. Adding further targets conventions is
straightforward and elided from this patch primarily to simplify the
review. Implemented in other branches are Linux X86, AMD64, AArch64 and
NVPTX.

Testing for targets that have existing lowering for va_arg from clang is
most efficiently done by checking that clang | opt completely elides the
variadic syntax from test cases. The lowering produces a struct for each
call site which can be inspected to check the various alignment and
indirections are correct.

AMDGPU presently has no variadic support other than some ad hoc printf
handling. Combined with the pass being inactive on all other targets
landing this represents strict increase in capability with zero risk.
Testing and refining will continue post commit.

In addition to the compiler tests included here, a self contained x64
clang/musl toolchain was constructed using the "lowering" instead of the
systemv ABI and used to build various C programs like lua and libxml2.