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

Move the m_GICmp match call in and use it to collect the operands.

This code is also needed for G_BRCOND.

Opaque ptr cleanup effort (NFC).

This patch is similar to a7acba29 but
for clangd.

It allows to pass non-UTF8 encoded command line arguments (e.g. path
where compile-commands.json file is located) on Windows.

This PR fixes https://github.com/llvm/llvm-project/issues/55013 : the
max intrinsics is not generated for this simple loop case :
https://godbolt.org/z/hxz1xhMPh. This is caused by a ICMP not being
folded into a select, thus not generating the max intrinsics.

For the story :

Since LLVM 14, SCCP pass got smarter by folding sext into zext for
positive ranges : https://reviews.llvm.org/D81756. After this change,
InstCombine was sometimes unable to fold ICMP correctly as both of the
arguments pointed to mismatched zext/sext. To fix this, @rotateright
implemented this fix : https://reviews.llvm.org/D124419 that tries to
resolve the mismatch by knowing if the argument of a zext is positive
(in which case, it is like a sext) by using ValueTracking, however
ValueTracking is not smart enough to infer that the value is positive in
some cases. Recently, @nikic implemented #67982 which keeps the
information that a zext is non-negative. This PR simply uses this
information to do the folding accordingly.

TLDR : This PR uses the recent nneg tag on zext to fold the icmp
accordingly in instcombine.

This PR also contains test cases for sext/zext folding with InstCombine
as well as a x86 regression tests for the max/min case.

This is to modify a list of libcxx tests written under the assumption
that iterators for std::array, std::string_view, and std::string are
pointers. The motivation for this PR is to make the tests more universal
and potentially being used to test other C++ standard library
implementations, for example
[microsoft/STL](https://github.com/microsoft/STL).

I can confirm that this patch makes a number of tests compatible with
microsoft STL:
`Failed :  204 (2.12%)`  ->  `Failed :  136 (1.42%)`
, and does not break any tests on `libcxx`.

This is not a complete list of such incompatibilities, but I am hoping
this will start a discussion about whether we are open to accepting such
changes.

Add support for bf16x2 instructions such as setp, fneg, fabs, etc;
Fix the instructions that were not differentiated between sm_80 and
sm_90 support, such as fpround etc.
Add more bf16 test cases to ensure the correct behavior.

---------

Co-authored-by: shenhan03 <shenhan03@kuaishou.com>

This patch moves creating the  middle VPBBs and an initial empty
vector loop region for the top-level loop to createInitialVPlan.

This consolidates code to create the initial VPlan skeleton and enables
adding other bits outside the main region during initial VPlan
construction. In particular, D150398 will add the exit check & branch to
the middle block.

Reviewed By: Ayal

Differential Revision: https://reviews.llvm.org/D158333

This patch doesn't work for do-while loops.

Fixed #64474.

This is consistent with other targets.

[RISCV][GISel] Rename PartialMappingIdx and ValueMappingsIdx to use register bank name with B suffix. NFC

PartialMappingIdx refers to an entry in the PartMappings table that
includes a RegBank and a size. So I think the PartialMappingIdx should
be named using the name of the register bank concatenated with the size.

So the indices are now PMI_GPRB32, PMI_GPRB64, PMI_FPRB32, PMI_FPRB64.