There are a number of and folds that are repeated for both
operand orders. Move these into a helper that is invoked with
both orders.

This is conceptually NFC, but may not be entirely so, as the order
of folds may change.

Alive2: https://alive2.llvm.org/ce/z/dHddwH
Fixes #69574

Replace getTypeForVPValue with the recently added, more general
VPTypeAnalysis.

When merging lane masks, value from block that is always visited first
(PrevReg in buildMergeLaneMasks) needs to exist because we do on-the-fly
constant folding. For PrevReg to exist, basic block that should contain
PrevReg definition must be processed first. Sort the incomings such that
incoming values that dominate other incoming values are processed first.

Sorting of phi incomings makes no changes for phis created by SDAG
because SDAG adds phi incomings as it selects basic blocks in reversed
post order traversal.

This change is required by upcoming lane mask merging implementation
for GlobalISel that leaves phi incomings as they are in IR.

This patch adds a --dependent-lib option to flang -fc1 on Windows to
embed library link options into the object file. This is needed to
properly select the Windows CRT to link against.

Cannot use the sign info for the roots for all scalars in the graph,
need to perform the analysis for each particular scalar (tree node).

Attempt to clarify the expected behaviour.

Currently there's an edge cases where constant indexing in target
regions can lead to incorrect results as we do not correctly replace
uses of mapped variables in generated target functions with the target
arguments (and accessor instructions) that replace them. This patch
seeks to fix that by extending the current logic in the OMPIRBuilder.

Things like GEP's can come in the form of Constants/ConstantExprs,
Constants and ConstantExpr's do not have access to the knowledge of what
they're contained in, so we must dig a little to find an instruction so
we can tell if they're used inside of the function we're outlining so we
can be sure they are replaceable and we are not accidentally replacing a
usage somewhere else in the module that's still necessary.

This patch handles these by replacing the original constant expression
with a new instruction equivalent; an instruction as it allows easy
modification in the following loop, as we can now know the constant
(instruction) is owned by our target function (as it holds this
knowledge) and replaceUsesOfWith can now be invoked on it (cannot do
this with constants it seems), a brand new one also allows us to be
cautious as it is perhaps possible the old expression was used inside of
the function but exists and is used externally (unlikely by the nature
of a Constant, but still a positive side affect).

This patch extends the vector.transpose lowering to replace:

vector.transpose %0, [1, 0] : vector<nx1x<eltty>> to vector<1xnx<eltty>>

with:

  vector.shape_cast %0 : vector<nx1x<eltty>> to vector<1xnx<eltty>>

Source with leading unit-dim (inverse) is also replaced. Unit dim must
be fixed. Non-unit dim can be scalable.

A check is also added to bail out for scalable vectors before unrolling.

Replace usage of StringRef::find_last_of with a string literal of size one by the equivalent char literal

Related patch: https://github.com/llvm/llvm-project/pull/68331
This missed optimization is discovered with the help of
https://github.com/AliveToolkit/alive2/pull/962.

When x is not known to be nonzero, ctpop(x) == 1 is expanded to

    x != 0 && (x & (x - 1)) == 0

resulting in codegen like

    leal    -1(%rdi), %eax
    testl   %eax, %edi
    sete    %cl
    testl   %edi, %edi
    setne   %al
    andb    %cl, %al

But another expression that works is

    (x ^ (x - 1)) > x - 1

which has nicer codegen:

    leal    -1(%rdi), %eax
    xorl    %eax, %edi
    cmpl    %eax, %edi
    seta    %al

Adjust the depth (number of #) for some sections.
Move an underscore prefix to a suffix in an example to let the Fortran
parser in the documentation generator pass.

Incoming block, incoming Register and updated incoming Register that
correspond to the same incoming of a phi are kept on same index in
different vectors.
Use structure with fields: block, register and updated register instead.

Similar to what we do in isArrayRoot() - only return true here if the
Pointee is actually of array type.

Both the Arm and X86 implementations of areLoadsFromSameBasePtr use a
switch over the machine opcode, and repeat the same logic for both
SDNode operands. We can avoid the duplicated logic (especially lengthy
in the X86 case) by just using a lambda. This could obviously be a
candidate for moving out to a separate helper function if there were
other users, but I've made the minimal change in this patch.

RunRandTest is driven by a fixed seed, not a random_device

AVX512 targets can just as easily use UINT_TO_FP/SINT_TO_FP, but pre-AVX512 only have SINT_TO_FP instructions

vecreduce_add(mul(ext, ext)) -> vecreduce_add(udot) 
vecreduce_add(ext) -> vecreduce_add(ext)

Vectors of scalar size of 8-bits with element count of multiples of 8

The bug was fixed by #71710.

This fixes https://github.com/llvm/llvm-project/issues/72323.

Resulted from
https://github.com/llvm/llvm-project/commit/f054947c0da99ec8b3c4bb043e5225672420a313

[lldb][DWARFASTParserClang] DWARFv5: support DW_TAG_variable static data members declarations (#72236)

The accepted DWARFv5 issue 161118.1: "DW_TAG for C++ static data
members" specifies that static data member declaration be described by
DW_TAG_variable. Make sure we recognize such members.

Depends on:
* https://github.com/llvm/llvm-project/pull/72234
* https://github.com/llvm/llvm-project/pull/72235

This patch implements the DWARFv5 issue 161118.1: "DW_TAG for C++ static
data members".

This will simplify LLDB's handling of static data members greatly in the
long term since we no longer need to differentiate non-static from
static data member declarations using non-portable heuristics.

Depends on:
* https://github.com/llvm/llvm-project/pull/72234

Allow foldImmediate to create instructions like:

  v_fmamk_f32 v0, s0, 0x42000000, v0

This instruction has two "scalar values": s0 and 0x42000000. On GFX10+
this is allowed. This fold was originally implemented before the
compiler supported GFX10, when all ASICs were limited to one scalar
value.

This was reverted because it broke the OCaml LLVM bindings.
Relanding the original patch but without changing the C-API.
They'll continue to work just fine as they do today. If in the
future there is a need to pass a new tag to the C-API for creating
static members, then we'll make the change to the OCaml bindings
at that time.

Original commit message:
"""
This patch adds the LLVM-side infrastructure to implement DWARFv5 issue
161118.1: "DW_TAG for C++ static data members".

The clang-side of this patch will simply construct the DIDerivedType
with a different DW_TAG.
"""

Reading implicit addend from a relocation site doesn't require a complete
`LinkGraph` edge. The operation is independent from `TargetSymbol`,
but constructing an `Edge` instance required one. This patch fixes the
inconsistency and simplifies some setup code from the error unittests.

Furthermore this patch prepares for the `Arm`/`Thumb`/`Data` helper
functions to be turned into implementation details. Exposing them in the
API causes unfortunate inconsistencies that we don't want to error-check
all the time, e.g. passing `Thumb_Call` to `readAddendArm()`.

This reverts commit 8434b0b9. #72216 

This commit broke the multiple buildbots, looks like the extension in
`NUM_PREDEF_TYPE_IDS` might have broken some inheriting usages, causing
indeterminate results for the compiler. Investigating the issue now.

Fixes section depth and removes annotation of source as HLFIR since this
is not currently understood by the lexer. Fixing these issues help
reduce warnings in the documentation CI for LLVM.

Credits for this description go to @ftynse in
<https://discourse.llvm.org/t/scf-dialect-vs-cfg/3524/2> and
@antiagainst in
<https://www.lei.chat/posts/mlir-codegen-dialects-for-machine-learning-compilers/>!
(Unless it's wrong of course, then it's my bad.)

EDIT: Also related:
<https://discourse.llvm.org/t/codegen-dialect-overview/2723

>.

---------

Co-authored-by: Mehdi Amini <joker.eph@gmail.com>

Factor out some stack allocation in a separate function. This patch
splits out the generic portion of a larger refactoring done as a part of
stack clash protection support.

The patch is almost, but not quite NFC. The only difference should
be that where we have adjacent allocation of stack space
for local SVE objects and non-local SVE objects the order
of `sub sp, ...` and `addvl sp, ...` instructions is reversed, because now
it's done with a single call to `emitFrameOffset` and it happens
add/subtract the fixed part before the scalable part, e.g.

    addvl sp, sp, #-2
    sub sp, sp, #16, lsl #12
    sub sp, sp, #16

becomes

    sub sp, sp, #16, lsl #12
    sub sp, sp, #16
    addvl sp, sp, #-2

Patch 3/3 of the transition step 1 described in

https://discourse.llvm.org/t/rfc-enabling-the-hlfir-lowering-by-default/72778/7

This patch changes bbc and flang-new driver to use HLFIR lowering by
default.

`-hlfir=false` can be used with bbc and `-flang-deprecated-no-hlfir`
with flang-new to get the previous default lowering behavior, but these
options will only be available for a limited period of time.

If any user needs these options to workaround bugs, they should open an
issue against flang in llvm github repo so that the regression can be
fixed in HLFIR.

This reverts commit 9a9933fa.

The OCaml bindings were using `LLVMDIBuilderCreateStaticMemberType`,
causing the API change in `9a9933fa`
to break buildbots that built the bindings. Revert until we figure out
whether to fixup the bindings or just not change the C-API

Due to a GCC bug (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25940),
GCC doesn't consider extern "C" functions with the same name but
different namespace to be the same. As such, the default visibility
attribute (on a declaration outside the namespace) doesn't get applied
to the definition in the namespace and the symbol is not exported.

This came up as an ABI diff when switching between gcc and clang for
compiling compiler-rt.

FileCheck currently compiles a regular expression of the form
`Prefix1|Prefix2|...` and uses it to find the next prefix in the input.

If we had a fast regex implementation, this would be a useful thing to
do, as the regex implementation would be able to match multiple prefixes
more efficiently than a naive approach. However, with our actual regex
implementation, finding the prefixes basically becomes O(InputLen *
RegexLen * LargeConstantFactor), which is a lot worse than a simple
string search.

Replace the regex with StringRef::find(), and keeping track of the next
position of each prefix. There are various ways this could be improved
on, but it's already significantly faster that the previous approach.

For me, this improves check-llvm time from 138.5s to 132.5s, so by
around 4-5%.

For vector-interleaved-load-i16-stride-7.ll in particular, test time
drops from 5s to 2.5s.

This patch adds the LLVM-side infrastructure to implement DWARFv5 issue
161118.1: "DW_TAG for C++ static data members".

The clang-side of this patch will simply construct the DIDerivedType
with a different DW_TAG.