Finds constants and function calls to math functions that can be
replaced with c++20's mathematical constants from the 'numbers' 
header and offers fix-it hints.
Does not match the use of variables with that value, and instead,
offers a replacement at the definition of those variables.

Rationale:
We no longer deal with topsort during sparsification, so that LoopId ==
LoopOrd for all methods. This first revision removes the types. A follow
up revision will simplify some other remaining constructs that deal with
loop order (e.g. at and ldx).

It turns out that CodeGenPrepare will skip over consecutive select
instructions as it knows it can optimise them all at the same time. This
is unfortunate for the RemoveDIs project to remove intrinsic-based
debug-info, because that means debug-info attached to those skipped
instructions doesn't get seen by optimizeInst and so updated. Add code
to handle debug-info on those skipped instructions manually.

This code will also have been slower when it had dbg.values stuffed in
between instructions, but with RemoveDIs it'll go faster because the
dbg.values won't break up the select sequence.

Minor simplification applied to VFShape::getScalarShape,
VFShape::get, and VFABI::tryDemangleForVFABI methods.

Also, remove unnecessary `static_cast` in `SLPVectorizer.cpp`

Original commit message below; asan complained about this commit because it
transpires that the final comparison with CurrentI is in fact a comparison
of a pointer that has been freed. This seems to work fine most of the time,
but using the iterator for such an instruction causes the freed instruction
memory to be accessed, causing a use-after-free. The fix is to perform the
comparison as an instruction, not an iterator.

[NFC][DebugInfo][RemoveDIs] Use iterators to insert in callsite-splitting (#74455)

This patch gets call site splitting to use iterators for insertion
rather than instruction pointers. When we switch on non-instr debug-info
this becomes significant, as the iterators are going to signal whether
or not a position is before or after debug-info.

NFC as this isn't going to affect the output of any existing test.

It was reported in the PR that commit caused clang giving errors for
code previously considered valid.
This reverts commit 6b1aa319.

C++23 removed `<ciso646>` from the standard library. The header is used
in a few places in order to pull in implementation-specific and feature
test macros. The new way of doing that is `<version>`, which should be
supported by all supported implementations. This change replaces all
those uses of `<ciso646>` with `<version>`.

This adds support for a HasTailCall flag on function call edges in the
ThinLTO summary. It is intended for use in aiding discovery of missing
frames from tail calls in profiled call stacks for MemProf of profiled
binaries that did not disable tail call elimination. A follow on change
will add the use of this new flag during MemProf context disambiguation.

The new flag is encoded in the bitcode along with either the hotness
flag from the profile, or the relative block frequency under the
-write-relbf-to-summary flag when there is no profile data.
Because we now will always have some additional call edge information, I
have removed the non-profile function summary record format, and we
simply encode the tail call flag along with a hotness type of none when
there is no profile information or relative block frequency. The change
of record format and name caused most of the test case changes.

I have added explicit testing of generation of the new tail call flag
into the bitcode and IR assembly format as part of the changes to
llvm/test/Bitcode/thinlto-function-summary-refgraph.ll. I have also
added round trip testing through assembly and bitcode to
llvm/test/Assembler/thinlto-summary.ll.

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

Patch by: Hassnaa Hamdi <hassnaa.hamdi@arm.com>

This reverts commit 9e50c6e6. A few assertion and verifier
errors have been fixed in the coalescer and allocator, so hopefully this sticks this time.

Adds builtins for:
- FCVT
- BFCVT
- FCVTZS
- FCVTZU
- SCVTF
- UCVTF
- BFCVTN
- FCVTN
- SQCVT
- SQCVTU
- UQCVT
- SQCVTN
- SQCVTUN
- UQCVTN

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

These are picked up from getMemOperandsWithOffsetWidth but weren't then
being passed through to shouldClusterMemOps, which forces backends to
collect the information again if they want to use the kind of heuristics
typically used for the similar shouldScheduleLoadsNear function (e.g.
checking the offset is within 1 cache line).

This patch just adds the parameters, but doesn't attempt to use them.
There is potential to use them in the current PPC and AArch64
shouldClusterMemOps implementation, and I intend to use the offset in
the heuristic for RISC-V. I've left these for future patches in the
interest of being as incremental as possible.

As noted in the review and in an inline FIXME, an ElementCount-style abstraction may later be used to condense these two parameters to one argument. ElementCount isn't quite suitable as it doesn't support negative offsets.

The function `genCommonBlockMember` is not specific to OpenMP, and it
could very well be a common utility. Move it to ConvertVariable.cpp
where it logically belongs.

This moves code from CheckSVEBuiltinFunctionCall into ParseSVEImmChecks
in preparation for #74064

It was brought up during the cache review that we shouldn't be using
'getSpelling', and instead should use the IdentifierInfo itself.  This
patch replaces all uses of it.

The template function call `CheckDescriptorEqInt(length.get(), 16)` is
deduced to have `INT_T` equal to `std::int32_t` instead of
`std::int64_t`, but the length descriptor points to a 64-byte storage.
The comparison does not work in a big endian.

It's permitted to have extra implicit-def operands of the same main
register
after the main register def. If there are implicit operands, use the
standard
legality checks which verify the operand contents.

Depends #73933

The test was updated by

opt -passes=early-cse -S
llvm/test/CodeGen/X86/avx512-broadcast-unfold.ll

No need to generate/spill/restore to cpu stack

Cleanup work to allow us to properly use isFPImmLegal and fix some regressions encountered while looking at #74304

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

Patch by: Hassnaa Hamdi <hassnaa.hamdi@arm.com>

The 'cache' construct takes a list of 'vars', which are array-section
style definitions. This patch implements the parsing, leaving the lower
bound and length of the bound as expressions, so that we can validate
they are the correct 'thing' in sema.

Since #73253, loops over tiles in SSA form (i.e. loops that take
`iter_args` and yield a new tile) are supported, so this patch updates
ArmSME lowerings to this form. This is a NFC, as it still lowers to the
same intrinsics, but this makes IR less 'surprising' at a higher-level,
and may be recognised by more transforms.


Example:

IR before:
```mlir
scf.for %tile_slice_index = %c0 to %num_tile_slices step %c1 
{
   arm_sme.move_vector_to_tile_slice 
     %broadcast_to_1d, %tile, %tile_slice_index : 
     vector<[4]xi32> into vector<[4]x[4]xi32>
}
// ... later use %tile
```
IR now:
```mlir
%broadcast_to_tile = scf.for %tile_slice_index = %c0 to %num_tile_slices
    step %c1 iter_args(%iter_tile = %init_tile) -> (vector<[4]x[4]xi32>)
{
   %tile_update = arm_sme.move_vector_to_tile_slice
      %broadcast_to_1d, %iter_tile, %tile_slice_index :
      vector<[4]xi32> into vector<[4]x[4]xi32>
  scf.yield %tile_update : vector<[4]x[4]xi32>
}
// ... later use %broadcast_to_tile
```

After https://github.com/llvm/llvm-project/pull/73301, all semantics
tests using `triple XXX` options need to have a
`REQUIRED: XX-registered-target` since the llvm::TargetMachine is needed
to get the llvm::DataLayout before semantics.

Fix three tests that lacked this.

Fixes:
https://lab.llvm.org/buildbot/#/builders/21/builds/87263
https://lab.llvm.org/buildbot/#/builders/268/builds/3841

We use X32 for gnux32 triples - X86 should be used for 32-bit triples

This makes libc++'s <filesystem> tests compatible with MSVC's STL.

In msvc_stdlib_force_include.h, we need to define 3 more macros:

- _CRT_DECLARE_NONSTDC_NAMES activates the POSIX names of
  `getcwd` etc. As the comment explains, we need this because
  we test with Clang `-fno-ms-compatibility`, which defines 
  `__STDC__` to `1`, which causes the UCRT headers to disable 
  the POSIX names by default.
- Then we need _CRT_NONSTDC_NO_WARNINGS to avoid emitting
  deprecation warnings about the POSIX names.
- Finally, we need `NOMINMAX` to seal away the ancient evil.

These macros are documented in https://learn.microsoft.com/en-us/cpp/c-runtime-library/compatibility?view=msvc-170.

As a drive-by change, the patch adds a "simulated" macro for 
__has_feature(hwaddress_sanitizer). It also clang-formats all
of msvc_stdlib_force_include.h and removes guards for
__has_builtin(__builtin_source_location) in <source_location>,
since those are not needed anymore.

Found while running libc++'s test suite with MSVC's STL.

This is a pure syntax cleanup, I don't need it for running libc++'s
tests with MSVC's STL.

This is possible because std::layout_meow and layout_wrapping_integral<1729>
aren't dependent types. We only need typename and template when reaching
into a dependent type, like `typename OtherLayout::template mapping<E2>` or
`typename layout_wrapping_integral<Wraps>::template mapping<Extents>`.

On AIX malloc(0) reutrns nullptr, which fails test case
`Evaluate/ISO-Fortran-binding.test`, using malloc(1) in AIX for
consistent behaviour

---------

Co-authored-by: Mark Danial <mark.danial@ibm.com>

Summary:
There are now a few cases that check if a symbol is present before
continuing, effectively making them optional features if present in the
image. This was done in at least three locations and required an ugly
operation to consume the error. This patch makes a utility function to
handle that instead.

Preliminary patch to change lowering/code generation to use
llvm::DataLayout information instead of generating "sizeof" GEP (see
https://github.com/llvm/llvm-project/issues/71507).

Fortran Semantic analysis needs to know about the target type size and
alignment to deal with common blocks, and intrinsics like
C_SIZEOF/TRANSFER. This information should be obtained from the
llvm::DataLayout so that it is consistent during the whole compilation
flow.

This change is changing flang-new and bbc drivers to:
1. Create the llvm::TargetMachine so that the data layout of the target
can be obtained before semantics.
2. Sharing bbc/flang-new set-up of the
SemanticConstext.targetCharateristics from the llvm::TargetMachine. For
now, the actual part that set-up the Fortran type size and alignment
from the llvm::DataLayout is left TODO so that this change is mostly an
NFC impacting the drivers.
3. Let the lowering bridge set-up the mlir::Module datalayout attributes
since it is doing it for the target attribute, and that allows the llvm
data layout information to be available during lowering.

For flang-new, the changes are code shuffling: the `llvm::TargetMachine`
instance is moved to `CompilerInvocation` class so that it can be used
to set-up the semantic contexts. `setMLIRDataLayout` is moved to
`flang/Optimizer/Support/DataLayout.h` (it will need to be used from
codegen pass for fir-opt target independent testing.)), and the code
setting-up semantics targetCharacteristics is moved to
`Tools/TargetSetup.h` so that it can be shared with bbc.

As a consequence, LLVM targets must be registered when running
semantics, and it is not possible to run semantics for a target that is
not registered with the -triple option (hence the power pc specific
modules can only be built if the PowerPC target is available.

This adds support for using dominating conditions in computeKnownBits()
when called from InstCombine. The implementation uses a
DomConditionCache, which stores which branches may provide information
that is relevant for a given value.

DomConditionCache is similar to AssumptionCache, but does not try to do
any kind of automatic tracking. Relevant branches have to be explicitly
registered and invalidated values explicitly removed. The necessary
tracking is done inside InstCombine.

The reason why this doesn't just do exactly the same thing as
AssumptionCache is that a lot more transforms touch branches and branch
conditions than assumptions. AssumptionCache is an immutable analysis
and mostly gets away with this because only a handful of places have to
register additional assumptions (mostly as a result of cloning). This is
very much not the case for branches.

This change regresses compile-time by about ~0.2%. It also improves
stage2-O0-g builds by about ~0.2%, which indicates that this change results
in additional optimizations inside clang itself.

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

Add commutative variant of m_DisjointOr.

Instead of linking to the doxygen documentation, link to the new sphinx
documentation instead.