Created using spr 1.3.5

Created using spr 1.3.5

[skip ci]

When you debug a binary and the change & rebuild and then rerun in lldb
w/o quitting lldb, the Modules in the Global Module Cache for the old
binary & .o files if used are now "unreachable". Nothing in lldb is
holding them alive, and they've already been unlinked. lldb will
properly discard them if there's not another Target referencing them.

However, this only works in simple cases at present. If you have several
Targets that reference the same modules, it's pretty easy to end up
stranding Modules that are no longer reachable, and if you use a
sequence of SBDebuggers unreachable modules can also get stranded. If
you run a long-lived lldb process and are iteratively developing on a
large code base, lldb's memory gets filled with useless Modules.

This patch adds a test for the mode that currently works:

(lldb) target create foo
(lldb) run
<rebuild foo outside lldb>
(lldb) run

In that case, we do delete the unreachable Modules.

The next step will be to add tests for the cases where we fail to do
this, then see how to safely/efficiently evict unreachable modules in
those cases as well.

Captures its responsibility a bit better.

1. A single dimension can either be blocked (with floordiv and mod pair)
or non-blocked. Mixing them would be invalid.
2. Block size should be non-zero value.

The AVX512F/AVX512BW checks had been removed despite still being used

Does transformations like
all_reduce(x) + all_reduce(y) -> all_reduce(x + y)

max(all_reduce(x), all_reduce(y)) -> all_reduce(max(x, y))
when the all_reduce element-wise op is max.

Added general rewrite pattern HomomorphismSimplification and
EndomorphismSimplification that encapsulate the general algorithm.
Made specialization for all-reduce with respect to
addf, addi, minsi, maxsi, minimumf and maximumf
in the Arithmetic dialect.

Add a configuration option to allow vector distribution with multiple
elements written by a single lane.

This is so that we can perform vector multi-reduction with multiple
results per workgroup.

Copy relocations and canonical PLT entries are for symbols defined in a
DSO. Currently we create them even for a `Defined`, possibly leading to
an output that won't work at run-time (e.g. R_X86_64_JUMP_SLOT
referencing a null symbol).
```
% cat a.s
.globl _start, main
.type main, @function
_start: main: ret

.rodata
.quad main
% clang -fuse-ld=lld -pie -nostdlib a.s
% readelf -Wr a.out

Relocation section '.rela.plt' at offset 0x290 contains 1 entry:
    Offset             Info             Type               Symbol's Value  Symbol's Name + Addend
00000000000033b8  0000000000000007 R_X86_64_JUMP_SLOT                        12b0
```

Report an error instead for the default `-z text` mode. GNU ld reports
an error in `-z text` mode as well.

Adding months to a year_month should wrap the year when the month
becomes greater than twelve or less than one.

This fixes the issue for year_month. Other classes with a year and month
do not have this issue. This has been verified and tests are added to
avoid possible regressions.

Also fixes some variable copy-paste errors in the tests.

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

When the main file is preprocessed and we change `MainFileName` to the
original source file name (e.g. `a.i => a.c`), the source manager does
not contain `a.c`, but we incorrectly associate the DIFile(a.c) with
md5(a.i). This causes CGDebugInfo::emitFunctionStart to create a
duplicate DIFile and leads to a spurious "inconsistent use of MD5
checksums" warning.

```
% cat a.c
void f() {}
% clang -c -g a.c  # no warning
% clang -E a.c -o a.i && clang -g -S a.i && clang -g -c a.s
a.s:9:2: warning: inconsistent use of MD5 checksums
        .file   1 "a.c"
        ^
% grep DIFile a.ll
!1 = !DIFile(filename: "a.c", directory: "/tmp/c", checksumkind: CSK_MD5, checksum: "c5b2e246df7d5f53e176b097a0641c3d")
!11 = !DIFile(filename: "a.c", directory: "/tmp/c")
% grep 'file.*a.c' a.s
        .file   "a.c"
        .file   0 "/tmp/c" "a.c" md5 0x2d14ea70fee15102033eb8d899914cce
        .file   1 "a.c"
```

Fix #56378 by disassociating md5(a.i) with a.c.

Adds the std.compat module and add support for CMake 3.28.

Make the hoisted dbg.declare inherent the DILocation scope from the new
storage.

After hoisting, the dbg.declare is moved into the block that defines the
new storage. This could create an inconsistency in the debug location
scope hierarchy where the scope of hoisted dbg.declare (i.e.
DILexicalBlock) is enclosed with the scope of the block (i.e.
DISubprogram). This confuses LiveDebugValues pass to think that the
hoisted dbg.declare is killed in that block and does not generate
DBG_VALUE in other blocks. Debugger won't be able to track its value
anymore.

This saves SimpleMachOHeaderMU subclasses from having to hold their own
reference.

When merging commit c873f77e I didn't
manually rebase it onto the tip of the main branch, so I didn't notice
that the testcase that's added by it needs to be tweaked to account for
the effects of commit 2f29ded4 (which
was also merged by me a few days ago).

- use more range for
- avoid capturing lambda
- prefer Register type to unsigned
- remove braces around single statement if

Before, it was only cleared if there were undefined entities. This is
important for Clang's incremental parsing as used by `clang-repl` that
might receive multiple calls to `Sema.ActOnEndOfTranslationUnit`.

This patch fixes:

  llvm/lib/Transforms/Scalar/SROA.cpp:4855:9: error: unused variable
  'NewAssign' [-Werror,-Wunused-variable]

Also, add a version option.

My builds were failing because the variable 'dim' was not used. This
produced a warning, and my builds have warnings set as errors.

These flags are usable on floating point arithmetic, as well as call,
select, and phi instructions whose resulting type is floating point, or
a vector of, or an array of, a valid type. Whether or not the flags are
valid for a given instruction can be checked with the new
LLVMCanValueUseFastMathFlags function.

These are exposed using a new LLVMFastMathFlags type, which is an alias
for unsigned. An anonymous enum defines the bit values for it.

Tests are added in echo.ll for select/phil/call, and the floating point
types in the new float_ops.ll bindings test.

Select and the floating point arithmetic instructions were not
implemented in llvm-c-test/echo.cpp, so they were added as well.

There are a few drive-by fixes:
- Since the combination RTTI disabled and exceptions enabled do not
work, this combination is prohibited.
- A small NFC in any fixing clang-tidy.

The code in the Buildkite configuration is prepared for using the std
module. There are more fixes needed for that configuration which will be
done in a separate commit.

Handle dbg.declares in SROA using DPValues.

In order to reduce duplication, the migrate-debug-info loop has been changed
to a generic lambda with some helper function overloads, which is called
for dbg.declares, dbg.assigns, and DPValues alike.

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

The folder for `tensor.extract` is not operating correctly when it is
consuming the result of a `tensor.from_elements` operation.

The existing unit test named `@extract_from_tensor.from_elements_3d` in
`mlir/test/Dialect/Tensor/canonicalize.mlir` seems an attempt to stress
this code. However, this unit tests creates a `tensor.from_elements` op
exclusively from constants, which gets folded away into a single
constant tensor. Therefore, the buggy code was never executed in unit
tests.

I have added a new unit test named
`@extract_from_tensor.from_elements_variable_3d` that makes sure the
`tensor.from_elements` op is not folded away by having its input
operands come directly from function arguments. The original folder code
would have made this test fail.

This bug was notably affecting the lowering of the `tosa.pad` op in the
`tosa-to-tensor` pass, where the generated code is likely to contain a
`tensor.from_elements` + `tensor.extract` op sequence.

The checker EnumCastOutOfRange verifies the (helpful, but not
standard-mandated) design rule that integer to enum casts should not
produce values that don't have a corresponding enumerator. As it was
improved and cleaned up by recent changes, this commit renames it from
`alpha.cplusplus.EnumCastOutOfRange` to `optin.core.EnumCastOutOfRange`
to reflect that it's no longer alpha quality.

As this checker handles a basic language feature (which is also present
in plain C), I moved it to a "core" subpackage within "optin".

In addition to the renaming, this commit cleans up the documentation in
`checkers.rst` and adds the new example code to a test file to ensure
that it's indeed producing the behavior claimend in the documentation.

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

Reviewed in PR (#71750). A part of [RFC - PGO Accuracy Metrics: Emitting and Evaluating Branch
and Block
Analysis](https://discourse.llvm.org/t/rfc-pgo-accuracy-metrics-emitting-and-evaluating-branch-and-block-analysis/73902).

This PR adds the PGOAnalysisMap data structure and implements encoding and
decoding through Object and ObjectYAML along with associated tests. When
emitted into the bb-addr-map section, each function is followed by the associated
pgo-analysis-map for that function. The emitting of each analysis in the map is
controlled by a bit in the bb-addr-map feature byte. All existing bb-addr-map
code can ignore the pgo-analysis-map if the caller does not request the data.

This adds support to help LLDB when binary is built with split dwarf,
has
.debug_names accelerator table and DWP file.
Final linked binary might have Type Units (TUs) with the same type
signature in multiple
compilation units. Although the signature is the same, TUs are not
guranted to
be bit identical. This is not a problem when they are in .o/.dwo files
as LLDB
can find them by looking at the right one based on
DW_AT_comp_dir/DW_AT_name in
skeleton CU. Once DWP is created, TUs are de-duplicated, and we need to
know
from which CU remaining one came from.

This approach allows LLDB to figure it out, with minimal changes to the
rest of
the tooling. As would have been the case if .debug_tu_index section in
DWP was
modified.

That patch was missing a recent change to the non-DPValue StoreInst overload.
Add it to the DPValue version. This is tested by
`llvm/tests/Transforms/Mem2Reg/dbg_declare_to_value_conversions.ll`,
which already has `--try-experimental-debuginfo-iterators`. It doesn't
fail currently because until #74090 lands the declares are not converted
to DPValues.

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

Also exposes a bit more of `FloatProperties` and adds documentation.
This should have been several patches but I was lazy.

The intrinsic variants of these functions don't do anything to
dbg.declares so the non-instruction variants should ignore them too.

Tested in llvm/test/DebugInfo/duplicate_dbgvalue.ll, which has
`--try-experimental-debuginfo-iterators` added in #73504.

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

This patch doesn't change any call sites.

Depends on #73498.

Reverted in 87c68670.