Semantics was replacing storage_size(func()) by the length specification
expression of func result (if any), which brought meaningless symbols.
Update FunctionRef::GetType to not copy its length parameter from the
procedure designator symbol if it is not a constant expression. Note
that the deferred aspect can and must be preserved because it matters
for POINTER function results (semantics test added to ensure this).

Update lowering code to deal with characters in storage_size: simply
always call createBox to ensure the BoxEleSizeOp is legal. This will
take care of dereferencing pointers/allocatables if needed (what the
load was intended for in the previous code).

17.0.1 is our most recent stable version which we decided to follow and
it fixes the issue described in llvm/llvm-project#67343

In order to support indirect vararg calls, we need to have information about the
callee type - this patch adds a `callee_type` attribute that holds that.

The attribute is required for vararg calls, else, it is optional and the callee
type is inferred by the operands and results of the operation if not present.

The syntax for non-vararg calls remains the same, whereas for vararg calls, it
is changed to this:

```
llvm.call %p(%arg0, %arg0) vararg(!llvm.func<void (i32, ...)>) : !llvm.ptr, (i32, i32) -> ()
llvm.call @s(%arg0, %arg0) vararg(!llvm.func<void (i32, ...)>) : (i32, i32) -> ()
```

The conditions of a noexcept and explicit specifier are full
expressions. Before this patch, we would call ActOnFinishFullExpr on
these in the context of the enclosing expression, which would cause the
collect of odr-used variables (and subsequently capture attempts) in the
wrong (enclosing) context.

This was observable when parsing the noexcept specifier condition of a
lambda appearing in a wider full expression odr-using variables.

Fixes #67492

[NFC] [C++20] [Modules] Refactor Module::getGlobalModuleFragment and Module::getPrivateModuleFragment

The original implementation of `Module::getGlobalModuleFragment` and
`Module::getPrivateModuleFragment` tried to find the global module
fragment and the private module fragment by comparing strings, which
smells bad. This patch tries to improve this.

A constant __builtin_abs(-14) cannot be evaluated without a running target
as Clang now emits llvm.abs.*

Co-authored-by: Wael Yehia <wyehia@ca.ibm.com>

When hosting a loop invariant instruction the resulting register must be
live in
all the basic blocks of the loop body and the killed flags of the
register must
be cleared.

Before this patch killed flags of subregister to a hoisted superregister
was not
cleared in the loop body.

This was found in an out of tree target, but the testcase
mlicm-stack-write-check.mir was modified to trigger the case.

…s with 2 addis in some cases.

If the lower 13 bits are something like 0x17ff, we can first materialize
it as 0x1800 followed by an addi to subtract a small offset. This might
be cheaper to materialize since the constant ending in 0x1800 can use a
simm12 immediate for its final addi.

https://llvm.org/github.com/llvm/llvm-project/issues/67586.

instcombine will combine neg+icmp+select to llvm.abs.*. Let's just emit
llvm.abs.* in the first place.

[RISCV][NFC] Move some common class/multiclass from riscv_vector.td to riscv_vector_common.td (#67587)

Since there are more vendor extensions that needs to implement
custom intrinsics, it's useful to move some common usages to
riscv_vector_common.td.

Adding support for X86_64 UEFI target to begin with.

Reviewed By: phosek, MaskRay

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

These two subroutines are almost the same except the LMUL encoding.

We can use `NFList` in `NFSet` to remove duplicated code.

Close https://github.com/llvm/llvm-project/issues/67627

In a module unit, all the declaration before the modoule declaration
should live in the GMF.

Lower G_ABS to support llvm.abs.* intrinsics.

The replacement could avoid an assignment to GPR when the type is vector
of i8/i16 and vwmaccu.wv which may have higher cost than vwsll.vi/vx.

We just forget to check for interrupt while waiting for the answer to the prompt. But if we are in the interrupt state then the lower
layers of the EditLine code just eat all characters so we never get out of the query prompt. You're pretty much stuck and have to kill lldb.

The solution is to check for the interrupt. The patch is a little bigger because where I needed to check the Interrupt state I only
had the ::EditLine object, but the editor state is held in lldb's EditLine wrapper, so I had to do a little work to get my hands on it.

This regression was introduced at LLVM-17 via
dc078e6e

"ld" may match a build direcory path, making the `-SAME:` pattern fail.

Noticed by chapuni:
https://github.com/llvm/llvm-project/pull/67445#pullrequestreview-1645422024

Fixes a test failure if X86 isn't in LLVM_TARGETS_TO_BUILD.

Examples:

1. `#ELL = #sparse_tensor.encoding<{ lvlTypes = [ "dense", "dense",
"compressed" ], dimToLvl = affine_map<(i,j)[c] -> (c*4*i, i, j)>
}>`
to
`#ELL = #sparse_tensor.encoding<{ map = [s0](d0, d1) -> (d0 * (s0 * 4) :
dense, d0 : dense, d1 : compressed)
}>`

2. `#CSR_SLICE = #sparse_tensor.encoding<{ lvlTypes = [ "dense",
"compressed" ], dimSlices = [ (1, 4, 1), (1, 4, 2) ]
}>`
to
`#CSR_SLICE = #sparse_tensor.encoding<{ map = (d0 :
#sparse_tensor<slice(1, 4, 1)>, d1 : #sparse_tensor<slice(1, 4, 2)>) ->
(d0 : dense, d1 : compressed)
}>`

This patch recommits 126f0374, reverted by
3ada774d, along with the missing dependence.

clang-format uses a heuristic to determine if a requires() is either a
requires clause or requires expression, based on what is in the
parentheses. Part of this heuristic assumed that a requires clause can
never contain a comma, however this is not the case if said comma is in
the template argument of a type.

This patch allows commas to appear in a requires clause if an angle
bracket `<` has been opened.

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

…r G_ANYEXT/G_TRUNC.

AArch64, Mips, and ARM do not have source constraints in their version
of selectCopy. I'm assuming we don't need it either.

We weren't constraining the destination register of G_ANYEXT/G_TRUNC
previously, but we got away with it in our tests because all their users
constrained them as a use. When I removed the source constraint from
selectCopy this stopped working.

https://github.com/llvm/llvm-project/pull/67490 broke 32bit builds by
having mismatched types in a call to `std::min"

This change standardizes on using `size_t` to avoid the mismatch.

This reverts commit 126f0374.

Reverting due to bot failures.

This reverts commit 1d5ccce1.

Broken bot:
* https://lab.llvm.org/buildbot/#/builders/220/builds/28440

Summary:
[The LLVM C library for GPUs](https://libc.llvm.org/gpu/) supports
standard function calls on the GPU that users are familiar with.
Currently, this requires that users include these manually. The support
for this library is dependent upon whether or not associated LLVM build
was built with the GPU C library support. This patch implicitly adds
these for an OpenMP offloading compilation if we find that the toolchain
contains the GPU declarations that allow us to use this.

I do not know how to test this, given that it requires information from
the resource directory in the install. That means it won't be present
for any internal tests. It works when I test it and the idea is simple
enough so it should be simple enough.

The `S_INLINEES` debug symbol is used to record all the functions that
are directly inlined within the current function (nested inlining is
ignored).

This change implements support for emitting the `S_INLINEES` debug
symbol in LLVM, and cleans up how the `S_INLINEES` and `S_CALLEES` debug
symbols are dumped.

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

Inspired by https://reviews.llvm.org/D139487 , but I apply manual fixes
when clang-tidy does not provide the best fix.