It is not possible to unroll a scalable vector at compile time. This
currently prevents transfer_writes from being lowered to
arm_sme.tile_writes (downstream).

Instruction Selection for G_VECREDUCE_ADD now uses TableGen

Runtime function GetPID calls the function getpid
from unistd.h or process.h base on the OS.

If there are function calls in the candidate loop and we have vectorized
variants available, try some wider VFs in case the conservative initial
maximum based on the widest types in the loop won't actually allow us
to make use of those function variants.

When instantiation function, a call to Sema::resetFPOption was used to
set the FP options associated with AST node. However this function also
cleared FP pragma stack, and it is incorrect. Template instantiation
takes place on AST representation and semantic information like the FP
pragma stack should not affect it. This was a reason for miscompilation
in some cases.

To make the Sema interface more consistent, now `resetFPOptions` does
not clear FP pragma stack anymore. It is cleared in
`FpPragmaStackSaveRAII`, which is used in parsing only.

This change must fix https://github.com/llvm/llvm-project/issues/69717
(Problems with float_control pragma stack in Clang 17.x).

-fveclib= allows users to choose a vectorized libm so that loops
containing math functions are vectorized.

This is implemented as much as possible in the same way as in clang. The
driver test in veclib.f90 is copied from the clang test.

The data size is required for implementing the `memmove` optimization
for `std::copy`, `std::move` etc. correctly as well as replacing
`__compressed_pair` with `[[no_unique_address]]` in libc++. Since the
compiler already knows the data size, we can avoid some complexity by
exposing that information.

Instead of using individual macros to turn off missing C library
features, we use the using_if_exists attribute now. This patch removes
the _LIBCPP_HAS_NO_FGETPOS_FSETPOS macro used to workaround missing
fgetpos and fsetpos on older versions of Android -- using_if_exists
should take care of those in the headers and we should add appropriate
XFAILs to the tests instead of using TEST_HAS_NO_FGETPOS_FSETPOS.

Patch 2/3 of the transition step 1 described in

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

All the modified tests are still here since coverage for the direct
lowering to FIR was still needed while it was default. Some already have
an HLFIR version, some have not and will need to be ported in step 2
described in the RFC.

Note that another 147 lit tests use -emit-fir/-emit-llvm outputs but do
not need a flag since the HLFIR/no HLFIR output is the same for what is
being tested.

Reland "[Support]Look up in top-level subcommand as a fallback when looking options for a custom subcommand (#71981)

Fixed build bot errors. 

- Use `StackOption<std::string>` type for the top level option. This
way, a per test-case option is unregistered when destructor of
`StackOption` cleans up state for subsequent test cases.
- Repro the crash with no test sharding `/usr/bin/python3
/path/to/llvm-project/build/./bin/llvm-lit -vv --no-gtest-sharding -j128
/path/to/llvm-project/llvm/test/Unit`. The crash is gone with the fix
(same no-sharding repro)

**Original commit message:**
**Context:**

- In https://lists.llvm.org/pipermail/llvm-dev/2016-June/101804.html and
commit
https://github.com/llvm/llvm-project/commit/07670b3e984db32f291373fe12c392959f2aff67,
`cl::SubCommand` is introduced.
- Options that don't specify subcommand goes into a special 'top level'
subcommand.

**Motivating Use Case:**
- The motivating use case is to refactor `llvm-profdata` to use
`cl::SubCommand` to organize subcommands. See
https://github.com/llvm/llvm-project/pull/71328. A valid use case that's
not supported before this patch is shown below

```
  // show-option{1,2} are associated with 'show' subcommand.
  // top-level-option3 is in top-level subcomand (e.g., `profile-isfs` in SampleProfReader.cpp)
  llvm-profdata show --show-option1 --show-option2 --top-level-option3
```

- Before this patch, option handler look-up will fail with the following
error message "Unknown command line argument --top-level-option3".
- After this patch, option handler look-up will look up in sub-command
options first, and use top-level subcommand as a fallback, so
'top-level-option3' is parsed correctly.

#70958 adds registers R16-R31 (EGPR), this patch
1. Introduces a new instruction prefix REX2
2. Supports encoding of EGPR with REX2 for legacy instructions in MAP
0/1
3. Supports encoding of EGPR with EVEX for the existing instructions in
EVEX space

RFC:

https://discourse.llvm.org/t/rfc-design-for-apx-feature-egpr-and-ndd-support/73031/4

Changed the recently added `FindConstantOnVariableDefinition` to
not rely on MemberAttributes being non-const.

Original commit message:
"""
This patch removes the Objective-C accessibility workaround added in
https://github.com/llvm/llvm-project/commit/5a477cfd90a8a12510518973fa450ae67372f199
(rdar://8492646). This allows us to make the local `MemberAttributes`
variable immutable, which is useful for some other work around this
function I was planning on doing.

We don't need the workaround anymore since compiler-support for giving
debuggers access to private ivars was done couple of years later in
https://github.com/llvm/llvm-project/commit/d6cb4a858db0592f6f946fd99a10a9dfcbea6ee9
(rdar://10997647).

**Testing**

* Test-suite runs cleanly
"""

The compiler currently abends with an impossible reg-to-reg copy when
producing a negative zero FP immediate on RV32 with -Zdinx. This is
because we emit a negation that uses FP registers. Emit the right node
to produce correct code.

Adds ":Support" to MLIRBindingsPythonCore deps

Revert "[CodeGen] -fsanitize=alignment: add cl::opt sanitize-alignment-builtin to disable memcpy instrumentation (#69240)"

This reverts commit e8fe4de6.

memcpy/memmove instrumentation for -fsanitize=alignment has been tested
on a huge code base. There were some cleanups but the number does not
justify a workaround.

This reverts commit 576f7ccf.

Causes build bot failure because new code started depending
on the non-constness of the MemberAttributes.

Caused by a badly resolved merge conflict

This patch removes the Objective-C accessibility workaround added in
https://github.com/llvm/llvm-project/commit/5a477cfd90a8a12510518973fa450ae67372f199
(rdar://8492646). This allows us to make the local `MemberAttributes`
variable immutable, which is useful for some other work around this
function I was planning on doing.

We don't need the workaround anymore since compiler-support for giving
debuggers access to private ivars was done couple of years later in
https://github.com/llvm/llvm-project/commit/d6cb4a858db0592f6f946fd99a10a9dfcbea6ee9
(rdar://10997647).

**Testing**

* Test-suite runs cleanly

Reland "[lldb][DWARFASTParserClang] Fetch constant value from variable defintion if available" (#71800)

This patch relands https://github.com/llvm/llvm-project/pull/71004 which
was reverted because the clang change it depends on was reverted.

In addition to the original patch, this PR includes a change to
`SymbolFileDWARF::ParseVariableDIE` to support CU-level variable
definitions that don't have locations, but represent a constant value.
Previously, when debug-maps were available, we would assume that a
variable with "static lifetime" (which in this case means "has a linkage
name") has a valid address, which isn't the case for non-locationed
constants. We could omit this additional change if we stopped attaching
linkage names to global non-locationed constants.

Original commit message:
"""
https://github.com/llvm/llvm-project/pull/71780 proposes moving the
`DW_AT_const_value` on inline static members from the declaration DIE to
the definition DIE. This patch makes sure the LLDB's expression
evaluator can continue to support static initialisers even if the
declaration doesn't have a `DW_AT_const_value` anymore.

Previously the expression evaluator would find the constant for a
VarDecl from its declaration `DW_TAG_member` DIE. In cases where the
initialiser was specified out-of-class, LLDB could find it during symbol
resolution.

However, neither of those will work for constants, since we don't have a
constant attribute on the declaration anymore and we don't have
constants in the symbol table.
"""

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

Catch asserts hit after 1adce7d8e47e2438f99f91607760b825e5e3cc37

Reland "[clang][DebugInfo] Emit global variable definitions for static data members with constant initializers" (#71780)

This patch relands https://github.com/llvm/llvm-project/pull/70639

It was reverted because under certain conditions we triggered an
assertion
in `DIBuilder`. Specifically, in the original patch we called
`EmitGlobalVariable`
at the end of `CGDebugInfo::finalize`, after all the temporary `DIType`s
have
been uniqued. With limited debug-info such temporary nodes would be
created
more frequently, leaving us with non-uniqued nodes by the time we got to
`DIBuilder::finalize`; this violated its pre-condition and caused
assertions to trigger.

To fix this, the latest iteration of the patch moves
`EmitGlobalVariable` to the
beginning of `CGDebugInfo::finalize`. Now, when we create a temporary
`DIType` node as a result of emitting a variable definition, it will get
uniqued
in time. A test-case was added for this scenario.

We also now don't emit a linkage name for non-locationed constants since
LLDB doesn't make use of it anyway.

Original commit message:
"""
When an LLDB user asks for the value of a static data member, LLDB
starts
by searching the Names accelerator table for the corresponding variable
definition DIE. For static data members with out-of-class definitions
that
works fine, because those get represented as global variables with a
location
and making them eligible to be added to the Names table. However,
in-class
definitions won’t get indexed because we usually don't emit global
variables
for them. So in DWARF we end up with a single `DW_TAG_member` that
usually holds the constant initializer. But we don't get a corresponding
CU-level `DW_TAG_variable` like we do for out-of-class definitions.

To make it more convenient for debuggers to get to the value of inline
static data
members, this patch makes sure we emit definitions for static variables
with
constant initializers the same way we do for other static variables.
This also aligns
Clang closer to GCC, which produces CU-level definitions for inline
statics and also
emits these into `.debug_pubnames`.

The implementation keeps track of newly created static data members.
Then in `CGDebugInfo::finalize`, we emit a global `DW_TAG_variable` with
a
`DW_AT_const_value` for any of those declarations that didn't end up
with a
definition in the `DeclCache`.

The newly emitted `DW_TAG_variable` will look as follows:
```
0x0000007b:   DW_TAG_structure_type
                DW_AT_calling_convention        (DW_CC_pass_by_value)
                DW_AT_name      ("Foo")
                ...

0x0000008d:     DW_TAG_member
                  DW_AT_name    ("i")
                  DW_AT_type    (0x00000062 "const int")
                  DW_AT_external        (true)
                  DW_AT_declaration     (true)
                  DW_AT_const_value     (4)

Newly added
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv

0x0000009a:   DW_TAG_variable
                DW_AT_specification     (0x0000008d "i")
                DW_AT_const_value       (4)
                DW_AT_linkage_name      ("_ZN2t2IiE1iIfEE")
```

This patch also drops the `DW_AT_const_value` off of the declaration
since we
now always have it on the definition. This ensures that the
`DWARFParallelLinker`
can type-merge class with static members where we couldn't attach the
constant
on the declaration in some CUs.
"""

Dependent changes:
* https://github.com/llvm/llvm-project/pull/71800

This PR generalize gpu-out-lining pass to take care of ops
`SymbolOpInterface` instead of just `func::FuncOp`.

Before this change, gpu-out-lining pass will skip `llvm.func`.
```mlir
module {
  llvm.func @main() {
    %c1 = arith.constant 1 : index
    gpu.launch blocks(%arg0, %arg1, %arg2) in (%arg6 = %c1, %arg7 = %c1, %arg8 = %c1) threads(%arg3, %arg4, %arg5) in (%arg9 = %c1, %arg10 = %c1, %arg11 = %c1) {
      gpu.terminator
    }
    llvm.return
  }
}
```

After this change, gpu-out-lining pass can handle llvm.func as well.

A constant value is unique in llvm context. InferAddressSpaces was
replacing its users in other functions as well. This leads to unexpected
behavior in our downstream use case after the pass.

InferAddressSpaces is a function passe, so it shall not modify functions
other than currently processed one.

Co-authored-by: Abhinav Gaba <abhinav.gaba@intel.com>

---------

Co-authored-by: Abhinav Gaba <abhinav.gaba@intel.com>

32 bit target may generate different SelectionDAG for jump table. 
Temporarily limit this test for 64bit X86 target only.

Similar to https://wg21.link/n4279

For example, insert_or_assign can be used to simplify
CodeGenModule::AddDeferredUnusedCoverageMapping in
clang/lib/CodeGen/CodeGenModule.cpp

Closes https://github.com/llvm/llvm-project/issues/61460.

We have FunctionParmPackExpr that serves as the unexpanded expression
but from which the visitor collects none, which may lead to assertion
failure during the template instantiation.

After #70147, all primary annotation types are stored directly in the
instruction and hence there's no need for the temporary storage we've
used previously for repopulating preserved annotations.

SGPR spill VGPRs are WWM registers so allow them to be allocated by
SIPreAllocateWWMRegs pass.
This intentionally prevents spilling of these VGPRs when enabled.

This fixes test fails on non-x86 target.

Add subrange tracking and handling for LiveIntervals during PHI
elimination.
This requires extending MachineBasicBlock::SplitCriticalEdge to also
update subrange intervals.

Test whether jump table BB has debug info after ISel.

This allows us to fold the G_ICMP operands into the conditional branch.

This reuses the helper function we have for folding a G_ICMP into
G_SELECT.

Normally, when __asan_option_detect_stack_use_after_return option is
set,
the instrumentation passed the adress of the shadow memory bytes to be
set, for detecting problems with local variables.
This can be a problem when the -fsanitize-stable-abi option is in
effect,
since the ABI implementation doesn't have means to communicate the
current shadow memory base address
back to its users.

This change addresses it simply by setting
__asan_shadow_memory_dynamic_address to zero. It means
that __asan_set_shadow_xx will be now called with the offset relative to
the current shadow memory
base, and the ABI implementation needs to adapt accordingly.

The other change here is to set
__asan_option_detect_stack_use_after_return to nonzer by default,
which is needed for instrumentation to take paths using the
__asan_shadow_memory_dynamic_address
and __asan_set_shadow_xx calls.

Co-authored-by: Mariusz Borsa <m_borsa@apple.com>