- Partially implements P2770R0 (http://wg21.link/p2770)
- Fixes https://wg21.link/LWG3698, https://wg21.link/LWG3700, and https://wg21.link/LWG3791
- join_with_view hasn't been done yet since this type isn't implemented yet
- Rename tuple test directory to match the standard (which changed in P2770R0)
- Rename join_view test directory to match the standard

This reverts commit 17b8f87f.

Buildbot: https://lab.llvm.org/buildbot/#/builders/77/builds/32927

The general convention inside LVI is that std::nullopt means that
a value has been pushed to the worklist. However, getEdgeValueLocal()
used it as an additional spelling for getOverdefined() instead.

The tests will become "live" once #74090 lands (see for more info).

Make the layering here similar to all the other methods:
LazyValueInfoImpl implements the underlying API returning a
ValueLatticeElement, and then LazyValueInfo exposes this as a
ConstantRange publicly.

Reformat one table and protect a couple of tables that we don't want to
reformat.

Reported by Static Analyzer tool:

In getSourceRangeToTokenEnd(clang::Decl const *, clang::SourceManager
const &, clang::LangOptions): A very large function call parameter
exceeding the high threshold is passed by value

pass_by_value: Passing parameter LangOpts of type clang::LangOptions
(size 1784 bytes) by value, which exceeds the high threshold of 512
bytes

This test checks if proper OpenMP device RTL function is called to
handle workshare loop for GPU.

The code generation for GPU worksharing loops is implemented by the
patch: https://github.com/llvm/llvm-project/pull/73360

Use of those variables is guarded by lastType, so they are not actually used uninitialized.

Use the helper in the getConstantRange() and
getConstantRangeAtUse() APIs as well. For that purpose move the
handling of isUnknown() into the helper as well.

This patch doesn't change any call sites.

Depends on #73498.

We're only working on integers here, so we don't need DataLayout
to determine the width.

This will result in larger atomic operations getting expanded to
`__atomic_*` libcalls via AtomicExpandPass, which matches what Clang
already does in the frontend.

Adds the following SME2 builtins:
 - svunpk (x2 & x4)

See https://github.com/ARM-software/acle/pull/217/files

Patch by David Sherwood <david.sherwood@arm.com>

Also start to expose some of the internals to avoid duplication.

This commits fixes a few subtle bugs where the method:
1. Declares a local `Status error` which eclipses the method's parameter
`Status &error`.
- The method then sets the error state to the local `error` and returns
without ever touching the parameter `&error`.
- This effectively traps the error state and its message from ever
reaching the caller.
- I also threw in a null pointer check in case the callee doesn't set
its `Status` parameter but returns `0`/`nullptr`.

2. Declares a local `Status deref_error` (good), passes it to the
`Dereference` method (also good), but then checks the status of the
method's `Status &error` parameter (not good).
- The fix checks `deref_error` instead and also checks for a `nullptr`
return value.
- There's a good opportunity here for a future PR that changes the
`Dereference` method to fold an error state into the `ValueObject`
return value's `m_error` instead of using a parameter.
...

We know the type is scalar type.

The adds a hlfir minloc intrinsic, similar to the minval intrinsic
already added, to help in the lowering of minloc. The idea is to later
add maxloc too, and from there add a simplification for producing minloc
with inlined elemental and hopefully less temporaries.

VALUE derived type are passed by reference outside of BIND(C) interface.
The ABI is much simpler and it is possible for these arguments to have
the OPTIONAL attribute.

In the BIND(C) context, these arguments must follow the C ABI for
struct, which may lead the data to be passed in register. OPTIONAL is
also forbidden for those arguments, so it is safe to directly use the
fir.type<T> type for the func.func argument.

Codegen is in charge of later applying the C passing ABI according to
the target (https://github.com/llvm/llvm-project/pull/74829).

The code only works on integer casts, and the only bitcasts
involving integers are trivial. The code as previously written
would try to handle things like float to integer bitcasts by
fetching a ConstantRange of a float value, which is an ill-defined
operation.

Adjust the silenceable failure message as we lower `tensor.unpack` as a
combination of `linalg.transpose` + `tensor.collapse_shape` and
`tensor.extract_slice`.

This patch sinks `EXPLICIT_BIT_MASK` into `get_explicit_mantissa` - the
only function using it. Then it sinks the content of
`FPCommonProperties` directly into `FPProperties`.

`EXPONENT_BIAS` is almost always used with signed arithmetic. Making it
an `int32_t` from the start reduces the chances to run into
implementation defined behavior (cast from unsigned to signed is
implementation-defined until C++20).


https://en.cppreference.com/w/cpp/language/implicit_conversion#:~:text=If%20the%20destination%20type%20is%20signed,arithmetic%20overflow%2C%20which%20is%20undefined).

For the remaining uses set it to true, matching the current
behavior.

This is a boring mechanical update to support DPValues that look like
dbg.declares in SelectionDAG.

The tests will become "live" once #74090 lands (see for more info).

This is back-ported to C++03 now, since clang accepts C++11 attributes
in C++03. https://godbolt.org/z/f7xG18bdE

We can reduce some code.

> We are re-using tryToMergePartialOverlappingStores, which requires
DeadSI to dominate DeadSI.

Should be "DeadSI to dominate KillingSI" because that's what the check
is for.

Using it for RHS is fine, as undef is UB in that case.

Rename to canonicalizeShuffleWithOp and begin adding SHUFFLE(UNARYOP(X),UNARYOP(Y)) -> UNARYOP(SHUFFLE(X,Y)) fold support.

This is only kicking in after legalization, so targets that expand bit counts are still duplicating but it helps with a few initial cases.

I'm investigating adding support for extensions/conversions as well, but this is a first step.

In the context of C/Fortran interoperability (BIND(C)), it is possible
to give the VALUE attribute to a BIND(C) derived type dummy, which
according to Fortran 2018 18.3.6 - 2. (4) implies that it must be passed
like the equivalent C structure value. The way C structure value are
passed is ABI dependent.

LLVM does not implement the C struct ABI passing for LLVM aggregate type
arguments. It is up to the front-end, like clang is doing, to split the
struct into registers or pass the struct on the stack (llvm "byval") as
required by the target ABI.
So the logic for C struct passing sits in clang. Using it from flang
requires setting up a lot of clang context and to bridge FIR/MLIR
representation to clang AST representation for function signatures (in
both directions). It is a non trivial task.
See
https://stackoverflow.com/questions/39438033/passing-structs-by-value-in-llvm-ir/75002581#75002581.

Since BIND(C) struct are rather limited as opposed to generic C struct
(e.g. no bit fields). It is easier to provide a limited implementation
of it for the case that matter to Fortran.

This patch:
- Updates the generic target rewrite pass to keep track of both the new
argument type and attributes. The motivation for this is to be able to
tell if a previously marshalled argument is passed in memory (it is a C
pointer), or if it is being passed on the stack (has the byval llvm
attributes).
- Adds an entry point in the target specific codegen to marshal struct
arguments, and use it in the generic target rewrite pass.
- Implements limited support for the X86-64 case. So far, the support
allows telling if a struct must be passed in register or on the stack,
and to deal with the stack case. The register case is left TODO in this
patch.

The X86-64 ABI implemented is the System V ABI for AMD64 version 1.0