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 genera...

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...

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%....

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