[RISCV] Add test cases to show missed opportunity to fold (sub C, (xor (setcc), 1)). NFC

(sub C, (xori X, 1)) can be folded to (add X, C-1) if X is 0 or 1.

This would avoid the xori and in some cases remove an instruction
neede to materialize the constant.

[InstCombine] convert second std::min argument to same type as first

Ensure both arguments to std::min have the same type in all data models.

[compiler-rt] Build with C++17 explicitly

We've started using C++17 constructs in compiler-rt now (e.g.
string_view in ORC), but when using the bootstrapping build, we won't
inherit the C++ standard from LLVM, and compilation may fail if we
default to an older standard. Explicitly build compiler-rt with C++17 in
a standalone build, which matches what other subprojects (e.g. Clang and
LLD) do.

Untangle the mess which is MachineBasicBlock::hasAddressTaken().

There are two different senses in which a block can be "address-taken".
There can be a BlockAddress involved, which means we need to map the
IR-level value to some specific block of machine code.  Or there can be
constructs inside a function which involve using the address of a basic
block to implement certain kinds of control flow.

Mixing these together causes a problem: if target-specific passes are
marking random blocks "address-taken", if we have a BlockAddress, we
can't actually tell which MachineBasicBlock corresponds to the
BlockAddress.

So split this into two separate bits: one for BlockAddress, and one for
the machine-specific bits.

Discovered while trying to sort out related stuff on D102817.

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

[Clang][BPF]: Force sign/zero extension for return values in caller

Currently bpf supports calling kernel functions (x86_64, arm64, etc.)
in bpf programs. Tejun discovered a problem where the x86_64 func
return value (a unsigned char type) is stored in 8-bit subregister %al
and the other 56-bits in %rax might be garbage. But based on current
bpf ABI, the bpf program assumes the whole %rax holds the correct value
as the callee is supposed to do necessary sign/zero extension.
This mismatch between bpf and x86_64 caused the incorrect results.

To resolve this problem, this patch forced caller to do needed
sign/zero extension for 8/16-bit return values as well. Note that
32-bit return values already had sign/zero extension even without
this patch.

For example, for the test case attached to this patch:

  $  cat t.c
  _Bool bar_bool(void);
  unsigned char bar_char(void);
  short bar_short(void);
  int bar_int(void);
  int foo_bool(void) {
        if (bar_bool() != 1) return 0; else return 1;
  }
  int foo_char(void) {
        if (bar_char() != 10) return 0; else return 1;
  }
  int foo_short(void) {
        if (bar_short() != 10) return 0; else return 1;
  }
  int foo_int(void) {
        if (bar_int() != 10) return 0; else return 1;
  }

Without this patch, generated call insns in IR looks like:
    %call = call zeroext i1 @bar_bool()
    %call = call zeroext i8 @bar_char()
    %call = call signext i16 @bar_short()
    %call = call i32 @bar_int()
So it is assumed that zero extension has been done for return values of
bar_bool()and bar_char(). Sign extension has been done for the return
value of bar_short(). The return value of bar_int() does not have any
assumption so caller needs to do necessary shifting to get correct
32bit values.

With this patch, generated call insns in IR looks like:
    %call = call i1 @bar_bool()
    %call = call i8 @bar_char()
    %call = call i16 @bar_short()
    %call = call i32 @bar_int()
There are no assumptions for return values of the above four function calls,
so necessary shifting is necessary for all of them.

The following is the objdump file difference for function foo_char().
Without this patch:
  0000000000000010 <foo_char>:
       2:       85 10 00 00 ff ff ff ff call -1
       3:       bf 01 00 00 00 00 00 00 r1 = r0
       4:       b7 00 00 00 01 00 00 00 r0 = 1
       5:       15 01 01 00 0a 00 00 00 if r1 == 10 goto +1 <LBB1_2>
       6:       b7 00 00 00 00 00 00 00 r0 = 0
  0000000000000038 <LBB1_2>:
       7:       95 00 00 00 00 00 00 00 exit

With this patch:
  0000000000000018 <foo_char>:
       3:       85 10 00 00 ff ff ff ff call -1
       4:       bf 01 00 00 00 00 00 00 r1 = r0
       5:       57 01 00 00 ff 00 00 00 r1 &= 255
       6:       b7 00 00 00 01 00 00 00 r0 = 1
       7:       15 01 01 00 0a 00 00 00 if r1 == 10 goto +1 <LBB1_2>
       8:       b7 00 00 00 00 00 00 00 r0 = 0
  0000000000000048 <LBB1_2>:
       9:       95 00 00 00 00 00 00 00 exit
The zero extension of the return 'char' value is done here.

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

Recommit "[RISCV] Use setcc's original SDLoc when inverting it in performSUBCombine."

This time using N1 instead of N0 since N1 points to the original
setcc. This now affects scheduling as I expected.

Original commit message:
We change seteq<->setne but it doesn't change the semantics
of the setcc. We should keep original debug location. This is
consistent with visitXor in the generic DAGCombiner.

Revert "[RISCV] Use setcc's original SDLoc when inverting it in performSUBCombine."

This reverts commit 1380b21ceba7b7b19e960da5df68dcd5cba1b091.

I mixed up N0 and N1 and didn't do what I intended.

[InstCombine] Add support for strlcpy folding

Reviewed By: efriedma

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

[RISCV] Use setcc's original SDLoc when inverting it in performSUBCombine.

We change seteq<->setne but it doesn't change the semantics
of the setcc. We should keep original debug location. This is
consistent with visitXor in the generic DAGCombiner.

[libc][Obvious] Rearrange few header targets to satisfy dependency order.

[LLDB][NFC] Fix optons parsing and misc. reliability in CommandObjectThread

* Improve reliability by checking return results for calls to FindLineEntryByAddress()
* Fix broken option parsing in SetOptionValue()

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

[unittests/CodeGen] Remove unique_ptr from the result of createTargetMachine

The object contained in unique_ptr will be automatically deleted at the end of
the current scope. In createMachineFunction,

  auto TM = createTargetMachine();

creates a TM contained in unique_ptr, a reference of the TM is stored in a
MachineFunction object, but at the end of the function, the TM is deleted, so
later access to the TM(and contained STI, TRI ...) through MachineFunction
object is invalid.

So we should not use unique_ptr<BogusTargetMachine> in functions
createMachineFunction and createTargetMachine.

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

[RISCV] Remove C!=0 restriction from (sub C, (setcc x, y, eq/neq)) -> (add C-1, (setcc x, y, neq/eq)).

While (sub 0, X) can use x0 for the 0, I believe (add X, -1) is
still preferrable. (addi X, -1) can be compressed, sub with x0 on
the LHS is never compressible.

[InstCombine] Remove assumptions about int having 32 bits

Reviewed By: bjope

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

[LLDB][NFC] Fix memory leak in IntstumentationRuntimeTSan.cpp

ConvertToStructuredArray() relies on its caller to deallocate the heap-allocated object pointer it returns. One of its call-sites, in GetRenumberedThreadIds(), fails to deallocate causing a memory/resource leak. Fix the memory leak by converting the return type to shared_ptr, and clean up the rest of the file to use the typedef-ed shared_ptr types for StructuredData for safety and consistency.

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

[Intrinsics] Add initial support for NonNull attribute

Add initial support for NonNull attribute.
(https://github.com/llvm/llvm-project/issues/57113)

Test plan:

verify that for
__thread int x;
int main() {

int* y = &x;
return *y;
}
(with this patch) clang -O -fsanitize=null -S -emit-llvm -o -
doesn't emit a null-pointer check

Differential revision: https://reviews.llvm.org/D131872

CodeGen: correct handling of debug info generation for aliases

When aliasing a static array, the aliasee is going to be a GEP which
points to the value.  We should strip pointer casts before forming the
reference.  This was occluded by the use of opaque pointers.

This problem has existed since the introduction of the debug info
generation for aliases in b1ea0191a42074341847d767609f66a26b6d5a41.  The
test case would assert due to the invalid cast with or without
`-no-opaque-pointers` at that revision.

Fixes: #57179

[mlir][sparse] Refactoring: remove Operation * from the argument list in utility functions

This patch remove the Operation *op from the argument list in utility functions, and directly pass the Location instead of calling op->getLoc().

This should make the code more clear, as the utility function (logically) does not relies on the operation that we are currently rewriting, and they behave the same regardless of the operation.

Reviewed By: aartbik, wrengr

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

[clang][deps] Compute command-lines for dependencies immediately

Instead of delaying the generation of command-lines to after all
dependencies are reported, compute them immediately. This is partly in
preparation for splitting the TU driver command into its constituent cc1
and other jobs, but it also just simplifies working with the compiler
invocation for modules if they are not "without paths".

Also change the computation of the default output path in
clang-scan-deps to scrape the implicit module cache from the
command-line rather than get it from the dependency, since that is now
unavailable at the time we make the callback.

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

[RISCV] Don't fold (sub C, (setcc x, y, eq/neq)) -> (add C-1, (setcc x, y, neq/eq)) if C-1 isn't simm12.

We still need to materialize the constant in a register and we
may not be removing all uses of the original constant so it may
increase code size.

[RISCV] Add more test cases for (sub C, (setcc x, y, eq/neq)) -> (add C-1, (setcc x, y, neq/eq)). NFC

In these test cases we do the transform, but the immediate is too
large to form an ADDI so it didn't save any instructions.

If the constant is opaque or has additional users we shouldn't do
the transform if it doesn't form an ADDI.

[RISCV] Move test from setcc-logic.ll to select-const.ll. NFC

Also add setne version of the test.

Add some common prefixes to reduce number of identical CHECK lines.

[mlir][sparse] Implements concatenate operation for sparse tensor

This patch implements the conversion rule for operation introduced in https://reviews.llvm.org/D131200.
Also contains integration test for correctness

Reviewed By: aartbik

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

[libc][Obvious] Convert an add_header target to add_header_library target.

[RISCV] (sub C, (setcc x, y, eq/neq)) -> (add C-1, (setcc x, y, neq/eq)) fold for FP setcc.

This introduce an xori in some cases. I don't believe it was the
intention of the original patch. This was an accident because
nonan FP equality compares also use SETEQ/SETNE.

Also pass the correct type to getSetCCInverse.

[RISCV] Add test cases to show where we inverted a fp setcc and introduced an extra xori.

In these tests we had (sub C, (seteq X, Y)) which we converted to
the (add (setne X, Y), C-1). We don't have a FNE compare instruction
so this created an XORI to invert an FEQ instruction.

This might be a good idea since it can save a constant materialization,
but does not appear to be the intention of the original patch.

[RISCV] Minor cleanups to performSUBCombine. NFC

-Rename variable NnzC -> N0C.
-Use SelectionDAG::getSetCC to reduce code.
-Use SDValue::getOperand instead of operator-> and SDNode::getOperand.

Initial steps to add another similar combine to this code.

[lldb] Fix warnings

This patch fixes:

  lldb/source/Plugins/Instruction/RISCV/EmulateInstructionRISCV.h:34:5:
  error: default label in switch which covers all enumeration values
  [-Werror,-Wcovered-switch-default]

and:

  lldb/source/Plugins/Instruction/RISCV/EmulateInstructionRISCV.cpp:194:21:
  error: comparison of integers of different signs: 'int' and 'size_t'
  (aka 'unsigned long') [-Werror,-Wsign-compare]

[Sema] Fix friend destructor declarations after D130936

I accidentally broke friend destructor declarations in D130936.

Modify it to skip performing the destructor name check if we have a dependent friend declaration.

Reviewed By: hubert.reinterpretcast

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

[FlattenCFG] avoid crash on malformed code

We don't have a dominator tree in this pass, so we
can't bail out sooner by checking for unreachable
code, but this is a minimal fix for the example in
issue #56875.

[NFC][PowerPC] Add missing NOCOMPAT checks for builtins-ppc-xlcompat.c

Followup patch to address request from https://reviews.llvm.org/D124093

Reviewed By: amyk

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

[clang][dataflow] Use llvm::is_contained()

Reviewed By: samestep, xazax.hun

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

Fix subrange liveness checking at rematerialization

This patch fixes an issue where an instruction reading a whole register would be moved during register allocation into a spot where one of the subregisters was dead.

The code to check whether an instruction can be rematerialized at a given point or not was already checking for subranges to ensure that subregisters are live, but only when the instruction being moved was using a subregister, this patch changes that so the subranges are checked even when the moved instruction uses the full register.

This patch also adds a case to the original test for the subrange checking that trigger the issue described above.

The original subrange checking code was introduced in this revision: https://reviews.llvm.org/D115278

And I've encountered this issue on AMDGPUs while working with DPC++: https://github.com/intel/llvm/issues/6209

Essentially the greedy register allocator attempts to move the following instruction:

```
%3961:vreg_64 = V_LSHLREV_B64_e64 3, %3078:vreg_64, implicit $exec
```

From `@3440` into the body of a loop `@16312`, but `%3078` has the following live ranges:

```
%3078 [2224r,2240r:0)[2240r,3488B:1)[16192B,38336B:1) 0@2224r 1@2240r  L0000000000000003 [2224r,3440r:0) 0@2224r  L000000000000000C [2240r,3488B:0)[16192B,38336B:0) 0@2240r
```

So `@16312e` `%3078.sub1` is alive but `%3078.sub0` is dead, so this instruction being moved there leads to invalid memory accesses as `3078.sub0` ends up being trashed and the result of this instruction is used as part of an address calculation for a load.

On the original ticket this issue showed up on gfx906 and gfx90a but not on gfx908, this turned out to be because on gfx908 instead of moving the shift instruction into the loop, its value is spilled into an ACC register, gfx906 doesn't have ACC registers and for gfx90a ACC registers are used like regular vector registers and so aren't used for spilling.

With this patch the original application from the DPC++ ticket works properly on gfx906, and the result of the shift instruction is correctly spilled instead of moving the instruction in the loop.

Original Author: npmiller

Reviewed by: rampitec

Submitted by: rampitec

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

Revert "flang: Fix flang build with -Wctad-maybe-unsupported"

-Wctad-maybe-unsupported is now disabled for flang so these explicit
deduction guides are not required.

This reverts commit 248591aabee7fcc5246b67879b6a71b0bbbc0b9c.

Revert "Some more from-the-hip ctad-maybe-unsupported fixes for flang"

-Wctad-maybe-unsupported is now disabled for flang so these explicit
deduction guides are not required.

This reverts commit ec3956b6e63c1524d6b024ba5db9ffcd7281ada0.

Disable -Wctad-maybe-unsupported in flang since it already uses the feature a lot

[LLDB][NativePDB] Add nullptr checking.

[libc++] Improve updating data files.

This changes makes it easier to update the Unicode data files used for
the Extended Graphme Clustering as added in D126971.

Reviewed By: ldionne, #libc

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

[libc++][format] Improve format buffer.

Allow bulk output operations on the buffer instead of adding one
code unit at a time. This has a huge performance benefit at the cost of
larger binary. This doesn't implement @vitaut's earlier suggestion to
avoid buffering for std::string when writing a strings. That can be done
in a follow-up patch.

There are some minor complications for the non-buffered format_to_n.
When writing one character at a time it's easy to detect when reaching
the limit n. This is solved by adding a small overhead for format_to_n.
When the next write would overflow it stores the data in the internal
buffer and copies that up-to n code units. The overhead isn't measured,
but it's expected to only be an issue for small values of n; for larger
values the general improvements will outweight the new overhead.

```
   text    data     bss     dec     hex filename
 349081    6096     440  355617   56d21 format.libcxx.out-baseline
 344442    6088     440  350970   55afa formatted_size.libcxx.out-baseline
4567980   57272     424 4625676  46950c formatter_float.libcxx.out-baseline
 718800   12472     488  731760   b2a70 formatter_int.libcxx.out-baseline
 376341    6096     552  382989   5d80d format_to.libcxx.out-beaseline

 370169    6096     440  376705   5bf81 format.libcxx.out
 365530    6088     440  372058   5ad5a formatted_size.libcxx.out
4575116   57272     424 4632812  46b0ec formatter_float.libcxx.out
 725936   12472     488  738896   b4650 formatter_int.libcxx.out
 397429    6096     552  404077   62a6d format_to.libcxx.out
```

For very small strings the new method is slower, from 4 characters
there's already a small gain.

```
Comparing ./format.libcxx.out-baseline to ./format.libcxx.out
Benchmark                                           Time             CPU      Time Old      Time New       CPU Old       CPU New
--------------------------------------------------------------------------------------------------------------------------------
BM_format_string<char>/1                         +0.0268         +0.0268            43            44            43            44
BM_format_string<char>/2                         +0.0133         +0.0133            22            22            22            22
BM_format_string<char>/4                         -0.0248         -0.0248            12            11            12            11
BM_format_string<char>/8                         -0.0831         -0.0831             6             6             6             6
BM_format_string<char>/16                        -0.2976         -0.2976             4             3             4             3
BM_format_string<char>/32                        -0.4369         -0.4369             3             2             3             2
BM_format_string<char>/64                        -0.6375         -0.6375             3             1             3             1
BM_format_string<char>/128                       -0.7685         -0.7685             2             1             2             1

```

The int benchmark has benefits for the simple formatting, but shines for
the complex formatting:
```
Comparing ./formatter_int.libcxx.out-baseline to ./formatter_int.libcxx.out
Benchmark                                                               Time             CPU      Time Old      Time New       CPU Old       CPU New
----------------------------------------------------------------------------------------------------------------------------------------------------
BM_Basic<uint32_t>                                                   -0.2307         -0.2307            60            46            60            46
BM_Basic<int32_t>                                                    -0.1985         -0.1985            61            49            61            49
BM_Basic<uint64_t>                                                   -0.3478         -0.3479            81            53            81            53
BM_Basic<int64_t>                                                    -0.3475         -0.3475            81            53            81            53
BM_BasicLow<__uint128_t>                                             -0.3388         -0.3388            86            57            86            57
BM_BasicLow<__int128_t>                                              -0.3431         -0.3431            86            57            86            57
BM_Basic<__uint128_t>                                                -0.2822         -0.2822           236           170           236           170
BM_Basic<__int128_t>                                                 -0.3107         -0.3107           219           151           219           151
Integral_LocFalse_BaseBin_AlignNone_Int64                            -0.5781         -0.5781           178            75           178            75
Integral_LocFalse_BaseBin_AlignmentLeft_Int64                        -0.9231         -0.9231          1156            89          1156            89
Integral_LocFalse_BaseBin_AlignmentCenter_Int64                      -0.9179         -0.9179          1107            91          1107            91
Integral_LocFalse_BaseBin_AlignmentRight_Int64                       -0.9238         -0.9238          1147            87          1147            87
Integral_LocFalse_BaseBin_ZeroPadding_Int64                          -0.9170         -0.9170          1137            94          1137            94
Integral_LocFalse_BaseBin_AlignNone_Uint64                           -0.5923         -0.5923           175            71           175            71
Integral_LocFalse_BaseBin_AlignmentLeft_Uint64                       -0.9251         -0.9251          1154            86          1154            86
Integral_LocFalse_BaseBin_AlignmentCenter_Uint64                     -0.9204         -0.9204          1105            88          1105            88
Integral_LocFalse_BaseBin_AlignmentRight_Uint64                      -0.9242         -0.9242          1125            85          1125            85
Integral_LocFalse_BaseBin_ZeroPadding_Uint64                         -0.9232         -0.9232          1139            88          1139            88
Integral_LocFalse_BaseOct_AlignNone_Int64                            -0.3241         -0.3241           100            67           100            67
Integral_LocFalse_BaseOct_AlignmentLeft_Int64                        -0.9322         -0.9322          1166            79          1166            79
Integral_LocFalse_BaseOct_AlignmentCenter_Int64                      -0.9251         -0.9251          1108            83          1108            83
Integral_LocFalse_BaseOct_AlignmentRight_Int64                       -0.9303         -0.9303          1136            79          1136            79
Integral_LocFalse_BaseOct_ZeroPadding_Int64                          -0.9264         -0.9264          1156            85          1156            85
Integral_LocFalse_BaseOct_AlignNone_Uint64                           -0.3116         -0.3116            96            66            96            66
Integral_LocFalse_BaseOct_AlignmentLeft_Uint64                       -0.9310         -0.9310          1168            81          1168            81
Integral_LocFalse_BaseOct_AlignmentCenter_Uint64                     -0.9281         -0.9281          1128            81          1128            81
Integral_LocFalse_BaseOct_AlignmentRight_Uint64                      -0.9299         -0.9299          1148            80          1148            80
Integral_LocFalse_BaseOct_ZeroPadding_Uint64                         -0.9288         -0.9288          1153            82          1153            82
Integral_LocFalse_BaseDec_AlignNone_Int64                            -0.3342         -0.3342            95            63            95            63
Integral_LocFalse_BaseDec_AlignmentLeft_Int64                        -0.9360         -0.9360          1157            74          1157            74
Integral_LocFalse_BaseDec_AlignmentCenter_Int64                      -0.9303         -0.9303          1128            79          1128            79
Integral_LocFalse_BaseDec_AlignmentRight_Int64                       -0.9369         -0.9369          1164            73          1164            73
Integral_LocFalse_BaseDec_ZeroPadding_Int64                          -0.9323         -0.9323          1157            78          1157            78
Integral_LocFalse_BaseDec_AlignNone_Uint64                           -0.3198         -0.3198            93            63            93            63
Integral_LocFalse_BaseDec_AlignmentLeft_Uint64                       -0.9351         -0.9351          1158            75          1158            75
Integral_LocFalse_BaseDec_AlignmentCenter_Uint64                     -0.9298         -0.9298          1128            79          1128            79
Integral_LocFalse_BaseDec_AlignmentRight_Uint64                      -0.9361         -0.9361          1157            74          1157            74
Integral_LocFalse_BaseDec_ZeroPadding_Uint64                         -0.9333         -0.9333          1151            77          1151            77
Integral_LocFalse_BaseHex_AlignNone_Int64                            -0.3020         -0.3020            89            62            89            62
Integral_LocFalse_BaseHex_AlignmentLeft_Int64                        -0.9357         -0.9357          1174            75          1174            75
Integral_LocFalse_BaseHex_AlignmentCenter_Int64                      -0.9319         -0.9319          1129            77          1129            77
Integral_LocFalse_BaseHex_AlignmentRight_Int64                       -0.9350         -0.9350          1161            75          1161            75
Integral_LocFalse_BaseHex_ZeroPadding_Int64                          -0.9293         -0.9293          1150            81          1150            81
Integral_LocFalse_BaseHex_AlignNone_Uint64                           -0.3056         -0.3057            86            59            86            59
Integral_LocFalse_BaseHex_AlignmentLeft_Uint64                       -0.9378         -0.9378          1174            73          1174            73
Integral_LocFalse_BaseHex_AlignmentCenter_Uint64                     -0.9341         -0.9341          1129            74          1130            74
Integral_LocFalse_BaseHex_AlignmentRight_Uint64                      -0.9361         -0.9361          1157            74          1157            74
Integral_LocFalse_BaseHex_ZeroPadding_Uint64                         -0.9315         -0.9315          1147            79          1147            79
Integral_LocFalse_BaseHexUpper_AlignNone_Int64                       -0.0019         -0.0019            91            90            91            90
Integral_LocFalse_BaseHexUpper_AlignmentLeft_Int64                   -0.9099         -0.9099          1162           105          1162           105
Integral_LocFalse_BaseHexUpper_AlignmentCenter_Int64                 -0.9041         -0.9041          1121           108          1121           108
Integral_LocFalse_BaseHexUpper_AlignmentRight_Int64                  -0.9086         -0.9086          1162           106          1162           106
Integral_LocFalse_BaseHexUpper_ZeroPadding_Int64                     -0.9057         -0.9057          1164           110          1164           110
Integral_LocFalse_BaseHexUpper_AlignNone_Uint64                      +0.0110         +0.0110            86            87            86            87
Integral_LocFalse_BaseHexUpper_AlignmentLeft_Uint64                  -0.9136         -0.9136          1161           100          1161           100
Integral_LocFalse_BaseHexUpper_AlignmentCenter_Uint64                -0.9078         -0.9078          1133           104          1133           104
Integral_LocFalse_BaseHexUpper_AlignmentRight_Uint64                 -0.9132         -0.9132          1177           102          1177           102
Integral_LocFalse_BaseHexUpper_ZeroPadding_Uint64                    -0.9091         -0.9091          1160           105          1160           105
```
Other benchmarks give similar results.

Reviewed By: #libc, ldionne

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

[test][libcxx] Don't XFAIL passing test with HWASAN

[mlir][math] Added basic support for FPowI operation.

The operation computes pow(b, p), where 'b' is floating point
and 'p' is a signed integer. The result's type matches 'b' type.
The operands must have the same shape.

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

[CMake] Cleanup the descriptions for gRPC options

As a followup to https://reviews.llvm.org/D131593, clean up gRPC related
option names and messages to make them more generic.

Some more from-the-hip ctad-maybe-unsupported fixes for flang

[ValueTracking] computeKnownBits - attempt to use a branch condition feeding a phi to improve known bits range (PR38280)

If computeKnownBits encounters a phi node, and we fail to determine any known bits through direct analysis, see if the incoming value is part of a branch condition feeding the phi.

Handle cases where icmp(IncomingValue PRED Constant) is driving a branch instruction feeding that phi node - at the moment this only handles EQ/ULT/ULE predicate cases as they are the most straightforward to handle and most likely for branch-loop 'max upper bound' cases - we can extend this if/when necessary.

I investigated a more general icmp(LHS PRED RHS) KnownBits system, but the hard limits we put on value tracking depth through phi nodes meant that we were mainly catching constants anyhow.

Fixes the pointless vectorization in PR38280 / Issue #37628 (excessive unrolling still needs handling though)

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

[LLDB][RISCV] Make software single stepping work

Add:
- `EmulateInstructionRISCV`, which can be used for riscv32 and riscv64.
- Add unittests for EmulateInstructionRISCV.

Note: Compressed instructions set (RVC) was still not supported in this patch.

Reviewed By: DavidSpickett

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

[LLDB] Handle possible resume thread error

In this switch case we didn't handle possible errors in `ResumeThread()`, it's hard to get helpful information when it goes wrong.

Reviewed By: DavidSpickett

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

[LLDB] Fix possible nullptr exception

Some architectures do not have a flag register (like riscv).
In this case, we should set it to `baton.m_register_values.end()` to avoid nullptr exception.

Reviewed By: DavidSpickett

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

[PhaseOrdering] Add test showing excessive unrolling of vector loop.

Test cases based on #42332 showing excessive unrolling with both known
and runtime trip counts.

[Windows] Put init_seg(compiler/lib) in llvm.global_ctors

Currently we treat initializers with init_seg(compiler/lib) as similar
to any other init_seg, they simply have a global variable in the proper
section (".CRT$XCC" for compiler/".CRT$XCL" for lib) and are added to
llvm.used. However, this doesn't match with how LLVM sees normal (or
init_seg(user)) initializers via llvm.global_ctors. This
causes issues like incorrect init_seg(compiler) vs init_seg(user)
ordering due to GlobalOpt evaluating constructors, and the
ability to remove init_seg(compiler/lib) initializers at all.

Currently we use 'A' for priorities less than 200. Use 200 for
init_seg(compiler) (".CRT$XCC") and 400 for init_seg(lib) (".CRT$XCL"),
which do not append the priority to the section name. Priorities
between 200 and 400 use ".CRT$XCC${Priority}". This allows for
some wiggle room for people/future extensions that want to add
initializers between compiler and lib.

Fixes #56922

Reviewed By: rnk

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

MSVC compatibility mode: fix error on unqualified templated base class initialization in case of partial specialization

I introduced a patch to handle unqualified templated base class
initialization in MSVC compatibility mode:
https://reviews.llvm.org/rGc894e85fc64dd8d83b460de81080fff93c5ca334
We identified a problem with this patch in the case where the base class
is partially specialized, which can lead to triggering an assertion in
the case of a mix between types and values.
The minimal test case is:

  template <typename Type, int TSize> class Vec {};
  template <int TDim> class Index : public Vec<int, TDim> {
    Index() : Vec() {}
  };
  template class Index<0>;

The detailed problem is that I was using the
`InjectedClassNameSpecialization`, to which the class template arguments
were then applied in order. But in the process, we were losing all the
partial specializations of the base class and creating an index mismatch
between the expected and passed arguments.

Patch By: frederic-tingaud-sonarsource

Reviewed By: rnk

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

[RS4GC] Handle vectors of pointers in non-live clobbering

Fix crash when trying to unconditionally cast alloca type to PointerType

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

[InstCombine] known-phi-br.ll - remove multiuse handling from tests

Based off discussion with @spatel for D131838 - InstCombine will still canonicalize the predicates enough that the @use() multiuses aren't helping

[CodeView] Use non-qualified names for static local variables

Static variables declared within a routine or lexical block should
be emitted with a non-qualified name.  This allows the variables to
be visible to the Visual Studio watch window.

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

[SLP]Fix PR51320: Try to vectorize single store operands.

Currently, we try to vectorize values, feeding into stores, only if
slp-vectorize-hor-store option is provided. We can safely enable
vectorization of the value operand of a single store in the basic block,
if the operand value is used only in store.
It should enable extra vectorization and should not increase compile
time significantly.
Fixes https://github.com/llvm/llvm-project/issues/51320

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

[LLVM][Debuginfod] Add missing thread include

One of our silent bots is currently failing:
https://lab.llvm.org/staging/#/builders/171/builds/169

With:
<...>/Debuginfod.cpp:298:23: error: no type named 'sleep_for' in namespace 'std::this_thread'
    std::this_thread::sleep_for(Interval);
    ~~~~~~~~~~~~~~~~~~^

Add missing thread include to that file,
which is what all the other users of sleep_for do.

I think we are seeing this now because we disabled
llvm threading for this builder. Maybe debuginfod should account
for that but that's for another time.

[clang][Darwin] Re-apply "Always set the default C++ Standard Library to libc++"

Newer SDKs don't even provide libstdc++ headers, so it's effectively
never valid to build for libstdc++ unless the user explicitly asks
for it (in which case they will need to provide include paths and more).

This is a re-application of c5ccb78ade81 which had been reverted in
33171df9cc7f because it broke the Fuchsia CI bots. The issue was that
the test was XPASSing because it didn't fail anymore when the
CLANG_DEFAULT_CXX_LIB was set to libc++, which seems to be done for
Fuchsia. Instead, the test only fails if CLANG_DEFAULT_CXX_LIB is
set to libstdc++.

As a fly-by fix, also adjust the triple used by various tests to
something that is supported. Those tests were shown to fail on
internal bots.

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

[instcombine] Test for zero initialisation optimisation of a product given fast flags

Precommit tests for D131672.

Reviewed By: fhahn

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

Fix build error: [FPEnv][EarlyCSE] Support for CSE when exception behavior is "ignore" or "maytrap" and the rounding mode is known.

This should fix these build bot errors:

Step 6 (build-check-mlir-build-only) failure: build (failure)
C:\buildbot\mlir-x64-windows-ninja\llvm-project\llvm\lib\Transforms\Scalar\EarlyCSE.cpp(124): error C2220: the following warning is treated as an error
C:\buildbot\mlir-x64-windows-ninja\llvm-project\llvm\lib\Transforms\Scalar\EarlyCSE.cpp(124): warning C4996: 'llvm::Optional<llvm::fp::ExceptionBehavior>::getValue': Use value instead.
C:\buildbot\mlir-x64-windows-ninja\llvm-project\llvm\lib\Transforms\Scalar\EarlyCSE.cpp(129): warning C4996: 'llvm::Optional<llvm::RoundingMode>::getValue': Use value instead.
C:\buildbot\mlir-x64-windows-ninja\llvm-project\llvm\lib\Transforms\Scalar\EarlyCSE.cpp(1386): warning C4996: 'llvm::Optional<llvm::fp::ExceptionBehavior>::getValue': Use value instead.
C:\buildbot\mlir-x64-windows-ninja\llvm-project\llvm\lib\Transforms\Scalar\EarlyCSE.cpp(1388): warning C4996: 'llvm::Optional<llvm::RoundingMode>::getValue': Use value instead.

[Sema] fix false -Wcomma being emitted from void returning functions

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

Reviewed By: aaron.ballman

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

[FPEnv][EarlyCSE] Support for CSE when exception behavior is "ignore" or "maytrap" and the rounding mode is known.

Previously we would only CSE constrained FP intrinsics in the default
floating point environment. Exception behavior of "strict" is still not
allowed since we are not allowed to remove any traps in that case.

There are no restrictions on CSE across function calls inside a function.

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

[cmake] Fix tablegen exports

This fixes some fallout from D131282. Currently, add_tablegen() will add the tablegen target to LLVM_EXPORTS and associates the install with LLVMExports. For non-standalone builds, this means that you end up with mlir-tblgen and clang-tblgen in LLVMExports.

However, these projects should instead be using MLIR_EXPORTS/MLIRTargets and CLANG_EXPORTS/ClangTargets. To fix this, add an extra EXPORT option and make use of get_target_export_arg() to create the correct export argument.

Reviewed By: ashay-github

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

[AArch64] Add `foldCSELOfCSEl` DAG combine

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

[InstSimplify] Add another and(x,c) case where the mask is redundant (and in fact can constant fold away)

[LV] Use variables instead of hard-coded metadata IDs in tests.

[AArch64] Add support for 256-bit non temporal loads

Currenlty all temporal loads are mapped to `LDP` or `LDR`. This patch will map all the non temporal 256-bit loads into `LDNP`. Future patches should address other non-temporal loads.

Reviewed By: fhahn, dmgreen

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

[CFG] Fix crash on CFG building when deriving from a template.

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

[ARM] Simplify the creation of escaped build attribute values

There is an existing mechanism to escape strings, therefore the
functions created to escape Tag_also_compatible_with values are not
really needed. We can simply use the pre-existing utilities.

Reviewed By: pratlucas

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

[ARM] Parse Tag_also_compatible_with attribute

The ARM Attribute Parser used to parse the value of also_compatible_with
as it is, disregarding the way it is encoded.

This patch does a context aware parsing of the also_compatible_with
attribute. Additionally, some error handling is also done for incorrect
cases.

Reviewed By: pratlucas

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

[X86] Fix a lowering issue of mask.compress which has undef float passthrough

Previously, LegaizeDAG didn't check mask.compress's passthrough might be float, and this lead to getConstant crash since it doesn't support fp

Reviewed By: RKSimon

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

[TypePromotion] Only search for PHI + ZExt promotion of Integers

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

[AArch64] Add tests to check for loop vectorization of non temporal loads

Reviewed By: fhahn

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

[LLDB][ARM] Remove unused LoadPseudoRegistersFromFrame function

https://reviews.llvm.org/D131658 identified a bug in this and
turns out it's not used anywhere.

Reviewed By: JDevlieghere, clayborg

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

[pseudo] Style tweaks forgotten in D130337. NFC

Return "[SCEV] Use context to strengthen flags of BinOps"

This reverts commit 354fa0b48008eca701a110badd6974bf449df257.

Returning as is. The patch was reverted due to a miscompile, but
this patch is not causing it. This patch made it possible to infer
some nuw flags in code guarded by `false` condition, and then someone
else to managed to propagate the flag from dead code outside.

Returning the patch to be able to reproduce the issue.

[test][libcxx] Use own feature for HWAsan

[test][libcxx] Disable new.delete.array tests for HWAsan

[LoongArch] Add codegen support for fabs

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

[LoongArch] Encode LoongArch specific ELF e_flags to binary by LoongArchTargetStreamer

Reference: https://github.com/loongson/LoongArch-Documentation
The last commit hash (main branch) is:
99016636af64d02dee05e39974d4c1e55875c45b

Note:
There are several PRs [1][2][3] that may affect the e_flags.
After they got closed or merged, we should update the implementation here accordingly.

[1] https://github.com/loongson/LoongArch-Documentation/pull/33
[2] https://github.com/loongson/LoongArch-Documentation/pull/47
[2] https://github.com/loongson/LoongArch-Documentation/pull/61

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

[NFC] Add unittest for inline functions in modules

Don't lower log1p(x) to log(1 + x).

The latter has accuracy issues around 0. The lowering in MathToLLVM is kept for now.

Reviewed By: bkramer

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

[BOLT][NFC] Extend debug logging in analyzeJumpTable

Reviewed By: rafauler

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

[ExecutionEngine] Fix a warning

This patch fixes the warning:

  llvm/lib/ExecutionEngine/JITLink/ELF_i386.cpp:66:11: error: unused
  type alias 'Base' [-Werror,-Wunused-local-typedef]

[clang-format] Fix aligning of java-style declarations

- Modify TokenAnnotator to work fine with java-style array declarations.
- Add test for aligning of java declarations.

Fixes #55931.

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

[SelectionDAG][NFC] Fix return type when used isConstantIntBuildVectorOrConstantInt
and isConstantFPBuildVectorOrConstantFP

Reviewed By: RKSimon

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

Re-apply "[JITLink] Introduce ELF/i386 backend " with correct authorship.

I (lhames) accidentally pushed 5f300397c6ae8fa7ca3547ec2b7a3cd844f3ed59 on
Kshitij Jain's behalf without updating the patch author first (my apologies
Kshitij!).

Re-applying with correct authorship.

https://reviews.llvm.org/D131347

Revert "[JITLink] Introduce ELF/i386 backend support for JITLink."

This reverts commit 5f300397c6ae8fa7ca3547ec2b7a3cd844f3ed59.

No functional issues, I just failed to correctly set authorship on the patch.

[gn build] Port 5f300397c6ae

[JITLink] Introduce ELF/i386 backend support for JITLink.

This initial ELF/i386 JITLink backend enables JIT-linking of minimal ELF i386
object files. No relocations are supported yet.

Reviewed By: lhames

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

[Driver] Support linking to compiler-rt for target AVR

Reviewed By: aykevl

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

flang: Fix flang build with -Wctad-maybe-unsupported

Shooting from the hip since I don't have a flang build locally, but
hopefully this works.

[lldb] Fetching symbols in the background with dsymForUUID

On macOS, LLDB uses the DebugSymbols.framework to locate symbol rich
dSYM bundles. [1] The framework uses a variety of methods, one of them
calling into a binary or shell script to locate (and download) dSYMs.
Internally at Apple, that tool is called dsymForUUID and for simplicity
I'm just going to refer to it that way here too, even though it can be
be an arbitrary executable.

The most common use case for dsymForUUID is to fetch symbols from the
network. This can take a long time, and because the calls to the
DebugSymbols.framework are blocking, it takes a while to launch the
process. This is expected and therefore many people don't use this
functionality, but instead use add-dsym when they want symbols for a
given frame, backtrace or module. This is a little faster because you're
only fetching symbols for the module you care about, but it's still a
slow, blocking operation.

This patch introduces a hybrid approach between the two. When
symbols.enable-background-lookup is enabled, lldb will do the equivalent
of add-dsym in the background for every module that shows up in the
backtrace but doesn't have symbols for. From the user's perspective
there is no slowdown, because the process launches immediately, with
whatever symbols are available. Meanwhile, more symbol information is
added over time as the background fetching completes.

[1] https://lldb.llvm.org/use/symbols.html

rdar://76241471

Differential revision: https://reviews.llvm.org/D131328

[lldb] Flush the global thread pool in Debugger::Terminate

Use the Initialize/Terminate pattern for the global thread pool to make
sure it gets flushed during teardown.

Differential revision: https://reviews.llvm.org/D131407

[EHStreamer] Omit @LPStart when function has no landing pads

When no landing pads exist for a function, `@LPStart` is undefined and must be omitted.

EH table is generally not emitted for functions without landing pads, except when the personality function is uknown (`!isNoOpWithoutInvoke(classifyEHPersonality(Per))`). In that case, we must omit `@LPStart` even when machine function splitting is enabled.

Reviewed By: MaskRay

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

Revert "[Driver] Support linking to compiler-rt for target AVR"

This reverts commit 44a647d21d946f8cc3eb7c1fea33311cf778f303.

[MLIR][SPIRV] Add intel joint matrix ops

Reviewed By: antiagainst

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

Enable -Wctad-maybe-unsupported in LLVM build

Warns on potentially unintended use of C++17 Class Template Argument
Deduction. Use of this feature with types that aren't intended to
support it may may future refactorings of those types more difficult -
so this warning fires whenever the feature is used with a type that may
not have intended to be used with CTAD (the warning uses the existence
of at least one explicit deduction guide to indicate that a type
intentionally supports CTAD - absent that, it's assumed to not be
intended to support CTAD & produces a warning).

This is disabled in libcxx because lots of the standard library is
assumed to provide ctad-usable APIs and the false positive suppression
in the diagnostic is based on system header classification which doesn't
apply in the libcxx build itself.

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

[test][llvm-reduce] Fix simplify-cfg.ll

D131920 broke some Windows bots with "x6" in the buildbot paths.
https://lab.llvm.org/buildbot#builders/123/builds/12276

[libc++] Implement `operator<=>` for `error_{code,condition}`

Implements part of P1614R2 "The Mothership has Landed"

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

[libc++] Implement `operator<=>` for `error_category`

Implements part of P1614R2 "The Mothership has Landed"

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

[mlgo] Add ability to create feature-gated development features in regalloc advisor

Currently there is no way to add in development features to the ML
regalloc evict advisor which is useful to have when working on feature
engineering/improving the current model. This patch adds in the ability
to add in development features to the ML regalloc evict advisor which
are gated by a runtime flag and not added in at all if not compiled in
LLVM development mode. This sets the stage for future work where we are
planning on upstreaming some of the newer features that we are currently
experimenting with.

Reviewed By: mtrofin

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