Complement #72610 (non-SHF_ALLOC sections). GCC-generated
.gcc_exception_table has the SHF_ALLOC flag and may contain
R_RISCV_SET_ULEB128/R_RISCV_SUB_ULEB128 relocations.

This PR adds promised interface declarations for
`ConvertToLLVMPatternInterface` in all the dialects that support the
`ConvertToLLVM` dialect extension.

Promised interfaces allow a dialect to declare that it will have an
implementation of a particular interface, crashing the program if one
isn't provided when the interface is used.

This is needed to properly support Zve32x.

Targets affected:

- NVPTX and BPF: set to 64 bits.
- ARC, Lanai, and MSP430: set to 0 (they don't implement atomics).

Those which didn't yet add AtomicExpandPass to their pass pipeline now
do so.

This will result in larger atomic operations getting expanded to
`__atomic_*` libcalls via AtomicExpandPass. On all these targets, this
now matches what Clang already does in the frontend.

The only targets which do not configure AtomicExpandPass now are:
- DirectX and SPIRV: they aren't normal backends.
- AVR: a single-cpu architecture with no privileged/user divide, which
could implement all atomics by disabling/enabling interrupts, regardless
of size/alignment. Will be addressed by future work.

ANDN/ORN/XNOR are like other ALU instructions. It should be able to be
predicated by the cpu that supports short-forward-branch.

1. Improve the 'errno' modeling.
2. Improve constraints of the arguments.

Msan does not unwind stack in malloc without origins, but we still need
trace
for fatal errors.

Push #77391 into the main.

The fpext conversion cost for 16 elements should be 4 from Znver4.

Support fast math flag in the conversion of `complex.mulf` op to
standard dialect.

See:
https://discourse.llvm.org/t/rfc-fastmath-flags-support-in-complex-dialect/71981

This is still broken after #77350. Disable the warning for now, and fix
properly once the buildbot it back to green.

Link: https://github.com/llvm/llvm-project/issues/77395

https://reviews.llvm.org/D44780 implemented rudimentary support for
OVERLAY. The start address and `AT(ldaddr)` in `OVERLAY [start] :
[NOCROSSREFS] [AT ( ldaddr )]` are not optional.

In addition, there are two issues:

* When the start address is `.`, subsequent sections don't share the
  address of the first overlay section.
* When the first overlay section is empty and discardable, `p_paddr` is
  incorrectly zero. This is because a discarded section has a zero
  address, causing `prev->getLMA() + prev->size` where `prev` refers to
  the first section to evaluate to zero.

This patch supports optional start address and LMA and fix the issues.
Close #77265

Pull Request: https://github.com/llvm/llvm-project/pull/77272

Fixes the following from GCC:

    llvm-project/libc/src/string/memory_utils/op_x86.h:236:24: error:
conversion from ‘long unsigned int’ to ‘uint32_t’ {aka ‘unsigned int’}
may
    change value [-Werror=conversion]
      236 |   return (xored >> 32) | (xored & 0xFFFFFFFF);
          |          ~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~

Link:
https://lab.llvm.org/buildbot/#/builders/250/builds/16236/steps/8/logs/stdio
Link: https://github.com/llvm/llvm-project/pull/74506

Bitwise clear and exclusive or
Add pattern for:
    xor x, (and y, not(z)) -> bcax x, y, z

This reverts commit c68a9d25.

sifive-p450 supports a very restricted version of the short forward
branch optimization from the sifive-7-series.

For sifive-p450, a branch over a single c.mv can be macrofused as a
conditional move operation. Due to encoding restrictions on c.mv, we
can't conditionally move from X0. That would require c.li instead.

The changes to tablegen made by
https://github.com/llvm/llvm-project/pull/76825 result in
`StmtClass::lastStmtConstant` changing from `StmtClass::WhileStmtClass`
to `StmtClass::GCCAsmStmtClass`. Since `CFG::BuildOptions::alwaysAdd` is
never called with a `WhileStmt`, this has flown under the radar until
now.

Once such test in which an out-of-bounds access occurs is
`test/Sema/inline-asm-validate.c`, among many others.

`nvvm_fabs_f`
`nvvm_fabs_ftz_f`

Unfortunately, llvm fabs is not equivalent to these intrinsics since
llvm fabs is defined to only set the sign bit to zero while these can
also flush subnormal inputs and modify NaNs.

`nvvm_round_d`
`nvvm_round_f`
`nvvm_round_ftz_f`

llvm.nvvm.round uses RNI, while llvm.round codegens to RZI. LLVM defines
llvm.round to use the same rounding as libm
`round[f]()`, which is not necessary the same as how we define
llvm.nvvm.round.

`nvvm_sqrt_rn_f`
`nvvm_sqrt_rn_ftz_f`

sqrt may be lowered to a less precise version of sqrt, such as
sqrt.approx in NVPTX depending on factors such as the value of
-nvptx-prec-sqrtf32. These intrinsics should always become the
corresponding NVPTX instructions.

`nvvm_add_rn_d`
`nvvm_add_rn_f`
`nvvm_add_rn_ftz_f`
`nvvm_mul_rn_d`
`nvvm_mul_rn_f`
`nvvm_mul_rn_ftz_f`

These nvvm intrinsics have an explicitly specified rounding mode (.rn).
They should always be lowered to a PTX instruction with the same
explicit rounding mode. Converting to fmul and fadd instructions result
in the PTX instructions without rounding modes specified. This can cause
issue because:

> An add [or mul] instruction with no rounding modifier defaults to
round-to-nearest-even and may be optimized aggressively by the code
optimizer. In particular, mul/add sequences with no rounding modifiers
may be optimized to use fused-multiply-add instructions on the target
device.

`nvvm_div_rn_f`
`nvvm_div_rn_ftz_f`
`nvvm_rcp_rn_f`
`nvvm_rcp_rn_ftz_f`

fdiv may be lowered to a less precise version of div, such as div.full
in NVPTX depending on factors such as the value of -nvptx-prec-divf32.
These intrinsics should always become the corresponding NVPTX
instructions.

This extension has been superseded by SPV_KHR_cooperative_matrix which
is supported across major vendors GPU like Nvidia, AMD, and Intel.

Given that the KHR version has been supported for nearly half a year,
drop the NV-specific extension to reduce the maintenance burden and code
duplication.

Summary:
The offloading entries right now are assumed to be baked into the binary
itself, and thus always valid whenever the library is executing. This
means that we don't need to copy them to additional storage and can
instead simply pass around references to it.

This is not likely to change in the expected operation of the OpenMP
library. Additionally, the indirection for the offload entry struct is
simply two pointers, so moving it by value is trivial.

This addresses cases (currently failing) where we throw a null
pointer-to-object and fixes #64953.

We are trying to satisfy the following bullet from the C++ ABI 15.3:

* the handler is of type cv1 T* cv2 and E is a pointer type that can be
converted to the type of the handler by either or both of:

  - a standard pointer conversion (4.10 [conv.ptr]) not involving
    conversions to private or protected or ambiguous classes.

  - a qualification conversion.

The existing implementation assesses the ambiguity of bases by computing
the offsets to them; ambiguous cases are then when the same base appears
at different offsets. The computation of offset includes indirecting
through the vtables to find the offsets to virtual bases.

When the thrown pointer points to a real object, this is quite efficient
since, if the base is found, and it is not ambiguous and on a public
path, the offset is needed to return the adjusted pointer (and ...

If a category has no options associated with it, the `--help-hidden`
command still shows that category with the annotation "This option
category has no options", and this is how it was implemented from the
beginning when the categories were introduced, see commit 0537a988. A
feature to hide unrelated options was added later, in
https://reviews.llvm.org/D7100. Now, if a tool needs to hide unrelated
options that are associated with categories, leaving some of them empty,
those categories will still be visible on the `--help-hidden` output,
even if they have no use for the tool; see the changes in
`llvm/test/tools/llvm-debuginfo-analyzer/cmdline.test` for an example.

The patch ensures that only categories with options are shown on both
main and hidden help output.

Disallow using the form with a separate argument,
"--thinlto-cache-dir dir", allow only the one with equals,
"--thintlo-cache-dir=dir". This is the only form that actually was
tested when this was added in
f794808b, and matches the ELF side,
where only the form with an equals is supported (and this was also the
case at the time when this option was added to the MinGW linker).

Similar to #77345, the buildbots are observing similar warnings for the
sse2
implementation.

llvm-project/libc/src/__support/HashTable/sse2/bitmask_impl.inc:36:13:
    error: suggest braces around initialization of subobject
    [-Werror,-Wmissing-braces]
    return {bitmask};
            ^~~~~~~
            {      }
llvm-project/libc/src/__support/HashTable/sse2/bitmask_impl.inc:45:13:
    error: suggest braces around initialization of subobject
    [-Werror,-Wmissing-braces]
    return {static_cast<uint16_t>(~mask_available().word)};
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            {                                            }

Link:
https://lab.llvm.org/buildbot/#/builders/163/builds/49350/steps/8/logs/stdio
Link: https://github.com/llvm/llvm-project/pull/74506

This is a follow-up to (#71613) and (#71961).

AddName gives no feedback other than if it succeeded whereas
AddNameWithErrorHandling gives you back an SBError object. I would like
to mark AddName as deprecated and direct folks to use
AddNameWithErorrHandling instead.

---------

Co-authored-by: Med Ismail Bennani <ismail@bennani.ma>

Currently the `tileConsumerAndFuseProducerGreedilyUsingSCFFor` method
greedily fuses through all slices that are generated during the tile and
fuse flow. That is not the normal use case. Ideally the caller would
like to control which slices get fused and which dont. This patch
introduces a new field to the `SCFTileAndFuseOptions` to specify this
control.

The contol function also allows the caller to specify if the replacement
for the fused producer needs to be yielded from within the tiled
computation. This allows replacing the fused producers in case they have
other uses. Without this the original producers still survive negating
the utility of the fusion.

The change here also means that the name of the function
`tileConsumerAndFuseProducerGreedily...` can be updated. Defering that
to a later stage to reduce the churn of API changes.

Fixes the following diagnostic:

    llvm-project/libc/src/sys/mman/linux/mmap.cpp:44:59: error: implicit
conversion loses integer precision: 'off_t' (aka 'long long') to 'long'
    [-Werror,-Wshorten-64-to-32]
     size, prot, flags, fd, offset);
                            ^~~~~~

It looks like off_t is a curious types on different platforms. FWICT,
it's 32b
on arm (at least for arm-linux-gnueabi) but 64b elsewhere (including 32b
riscv32-linux-gnu).

Reverts llvm/llvm-project#75999

lit test is failing.

When --gcc-triple is used, the driver will search for the 'best' gcc
installation that has the given triple. This is useful for distributions
that want clang to use a specific gcc triple, but do not want to pin to
a specific version as would be required by using --gcc-install-dir.
Having clang linked to a specific gcc version can cause clang to stop
working when the version of gcc installed on the system gets updated.

…on (zero-copy) on MI300A.

This patch enables applications that did not request OpenMP
unified_shared_memory to run with the same zero-copy behavior, where
mapped memory does not result in extra memory allocations and memory
copies, but CPU-allocated memory is accessed from the device. The name
for this behavior is "automatic zero-copy" and it relies on detecting:
that the runtime is running on a MI300A, that the user did not select
unified_shared_memory in their program, and that XNACK (unified memory
support) is enabled in the current GPU configuration. If all these
conditions are met, then automatic zero-copy is triggered.

This patch is still missing support for global variables, which will be
provided in a subsequent patch.

Co-authored-by: Thorsten Blass <thorsten.blass@amd.com>

The 'self' clause takes an optional 'condition' expression, same as the
non-optional expression taken by the 'if' clause.  This patch extracts
the 'condition' expression to a separate function, and implements the
'optional parens' infrastructure for clauses, then implements 'self'
parsing.

Specializations of AccelTableBase are always interested in accessing the
derived versions of their data classes (e.g. DWARF5AccelTableData). They
do so by sprinkling `static_casts` all over the code.

This commit adds a helper function to simplify this process, reducinng
the number of casts that have to be made in the middle of code, making
it easier to read.