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.

It's rather disturbing that malformed syntax does not generate any
warnings or errors when building either locally or on the bots.

Tests to exercise vectorization of function calls where a vector variant
takes a linear parameter.

These tests were broken after
https://github.com/llvm/llvm-project/pull/74315

Fixing them to ignore the fastmath attribute on fcmp

We perform do this check independently of whether this is an old
or new style load.

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

This PR introduce `fence.mbarrier.init` OP

I'd copied and adjusted the doc comments for LLVMGetNNeg and LLVMSetNNeg
in #74517. Nikita pointed out in that review my comments were missing a
full stop, so I'm applying the same fix to these.

Follows #73952 doing the same thing for the nneg flag on zext (i.e.,
exposing support in the C API).

We can't easily convert this to use the update scripts, but we can manually improve the checks so we check for the right number of stores

Unblock build bot, while investigating. Issue is tracked under llvm
https://github.com/llvm/llvm-project/issues/74582

Found while running libc++'s tests with MSVC's STL.

`ranges::rotate_copy` takes `forward_iterator`s as this test's comment
banner correctly depicts. However, this test had bogus assertions
expecting that `ranges::rotate_copy` would be constrained away for
not-quite-**bidi** iterators. @philnik777 confirmed that these were
copy-paste relics from the `ranges::reverse_copy` test.

I fixed this by replacing the assertions with the test types that aren't
quite **forward** iterators/ranges. Additionally, I noticed that the
top-level `test()` function was missing coverage with the weakest
possible `forward_iterator<int*>`.

This revealed that the product code in `ranges_rotate_copy.h` was
similarly damaged. In addition to fixing it by taking `forward_iterator`
and `forward_range` as depicted in the Standard, this drops the
inclusion of `<__iterator/reverse_iterator.h>` as this algorithm doesn't
need `std::__reverse_range`.