[MergeICmps] Adapt to non-eq comparisons, bugfix

Fix the last runtime issue as some sequent comparisons need be spilted.
For the origin equal comparisons chain, the new spilted Icmp chain will
still be end with equal, while for the new not-equal comparisons chain,
the new spilted Icmp chain will still be end with equal, so should address
this carefully, see detail wih case partial_sequent_ne

Thanks for @aeubanks, @glandium and @ayzhao report the runtime issue
and carefully examine.
Fix https://github.com/llvm/llvm-project/issues/59740.

Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D141188

[mlir][openacc] Cleanup acc.update from old data clause operands

Since the new data operand operations have been added in D148389 and
adopted on acc.update in D149909, the old clause operands are no longer
needed. This is a first patch to start cleaning the OpenACC operations
with data clause operands.

The `LegalizeDataOpForLLVMTranslation` will become obsolete when all
operations will be cleaned. For the time being only the appropriate
part are being removed.

`processOperands` will also receive some updates once all the operands
will be coming from an acc data operand operation.

Reviewed By: razvanlupusoru, jeanPerier

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

Use LLVM-style include guard in regex_impl.h

The previous include guard (_REGEX_H_) is also used in a macOS SDK
header (xlocale.h), causing potential for trouble. This was previously
addressed in 2b8b90a7686858b1d22cae6fcfbd0904135112aa, but renaming the
macro in line with LLVM's other include guards seems like a better fix.

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

[RISCV] Implement shouldTransformSignedTruncationCheck.

This helps avoid constant materialization for the patterns
InstCombine emits for something like INT_MIN <= X && x <= INT_MAX.

See top of changed test files for more detailed explanation.

I've enabled this for i16 when Zbb is enabled. sext.b did not seem
to be a benefit due to the constants folding into addi/sltiu.

This an alternative to https://reviews.llvm.org/D149814

Reviewed By: reames

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

[RISCV] Simplify matchRegisterNameHelper interface. NFC

This previously returned a bool to indicate success or failure and
returns a register through an output parameter.

Some callers used the bool to check for success. Some callers checked
for RISCV::NoRegister.

To make everything uniform, return the MCRegister directly and update
all callers to use MCRegister::isValid().

Reviewed By: barannikov88

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

[lldb] Prevent mutation of CommandAlias::GetOptionArguments

Fix a mutation of `CommandAlias::m_option_args_sp`, which resulted in cases where
aliases would fail to run on second, and subsequent times.

For example, an alias such as:

```
command alias p1 p 1
```

When run the second time, the following error would be reported to the user:

```
error: expression failed to parse:
error: <user expression 1>:1:1: expression is not assignable
--  1
^   ~
```

To fix this, `CommandAlias::Desugar` now constructs options to a freshly constructed
vector, rather than by appending to the results of `GetOptionArguments`.

rdar://107770836

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

[Clang] Improve compile times when forming a DeclRef outside of a capturing scope.

The logic of whether an entity needs to be captured has become
quite complex and the recent changes in https://reviews.llvm.org/D124351
ad a mesurable negative impact on compile times.

However, in the absence of capturing scopes (lambda, block, region)
we usually can avoid running most of that logic
(except that we do need to diagnostic when a nested function
refers to a local variable in the scope of the outer function.).

This patch track whether there is currently an active capturing
scope and exit `tryCaptureVariable` early when there isn't.

Reviewed By: aaron.ballman

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

[libc][rpc][nfc] Encapsulate access to outbox pointer

Reviewed By: jhuber6

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

[mlir][openacc] Add verifier for dataOperands on compute operations

Data operands associated with acc.parallel, acc.serial and
acc.kernels should comes from acc data entry/exit operations
or acc.getdeviceptr.

Reviewed By: razvanlupusoru, jeanPerier

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

[mlir][opeancc] Update acc.update verifier for dataOperands

Data operands associated with acc.update should comes
from acc data entry/exit operations or acc.getdeviceptr.

Reviewed By: razvanlupusoru

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

[VPlan] Record IR flags on VPWidenRecipe directly (NFC).

This patch introduces a VPRecipeWithIRFlags class to record various IR
flags for a recipe. This allows de-coupling of IR flags from the
underlying instructions. The main benefit is that it allows dropping of
IR flags from recipes directly, without the need to go through
State::MayGeneratePoisonRecipes. The plan is to remove
MayGeneratePoisonRecipes once all relevant recipes are transitioned.

It also allows dropping IR flags during VPlan-to-VPlan transforms, which
will be used in a follow-up patch to implement truncateToMinimalBitwidths
as VPlan-to-VPlan transform.

Reviewed By: Ayal

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

[mlir][openacc] Update acc.enter_data verifier for dataOperands

Data operands associated with acc.enter_data should comes
from acc data entry operations.

Reviewed By: razvanlupusoru

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

[mlir][openacc] Update acc.data verifier for dataOperands

Data operands associated with acc.data should comes
from acc data entry/exit operations or acc.getdeviceptr.

Reviewed By: razvanlupusoru

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

Skip test when compiling with older versions of clang

[libc] Make the opcode parameter a compile time constant

Currently the opcode is only valid if it is the same between all of the
ports. This is possible to violate if the opcode is places into a memory
location and then read in a non-uniform manner by the warp / wavefront.
Moving this to a compile time constant makes it impossible to break this
invariant.

Reviewed By: JonChesterfield

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

[X86][MC] Reject `call`/`jmp [offset fn_ref]` in Intel syntax

This syntax is confusing and likely invalid. In addition, MASM rejects
it and GAS seems to behave oddly with it. Therefore we shall reject this
syntax for both unconditional `call` and `jmp` instructions, as
discussed in D149579.

Depends on D150047

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

[X86][CodeGen] Do not add `offset` for memory reference using symbol

In the past, D71436 added writing the `offset` operator for some
legitimate cases. However, for memory references in Intel syntax, the
`offset` operator (`[offset sym]`) appears to be superfluous at best,
possibly wrong and contradictory at worst.

This patch bypasses writing the `offset` operator in
`X86AsmPrinter::PrintIntelMemReference` which affects exactly this
case. A similar code flow exists in `X86IntelInstPrinter.cpp` -
`X86IntelInstPrinter::printMemReference`.

The motivation for fixing this output is to allow us to reject the
confusing `call [offset fn_ref]` syntax in MC, as discussed in D149579.

Depends on D149579

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

[X86][MC] Fix parsing Intel syntax indirect branch with symbol only

Clang on Windows targets often requires indirect calls through the
import address table (IAT), and also .refptr stubs for MinGW target.
On 32-bit this generates assembly in the form of
`call dword ptr [__imp__func]`, which MC had failed to handle correctly.
64-bit targets are not affected because rip-relative addressing is used.

Reported on: https://github.com/llvm/llvm-project/issues/62010

Depends on D149695, D149920

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

[MLIR][python bindings] Add `PyValue.print_as_operand` (`Value::printAsOperand`)

Useful for easier debugging (no need to regex out all of the stuff around the id).

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

Adopt Properties to store operations inherent Attributes in the Async dialect

This is part of an on-going migration to adopt Properties inside MLIR.

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

Adopt Properties to store operations inherent Attributes in the ARMSVE dialect

This is part of an on-going migration to adopt Properties inside MLIR.

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

Adopt Properties to store operations inherent Attributes in the ARMNeon dialect

This is part of an on-going migration to adopt Properties inside MLIR.

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

Adopt Properties to store operations inherent Attributes in the AMX dialect

This is part of an on-going migration to adopt Properties inside MLIR.

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

Adopt Properties to store operations inherent Attributes in the AMDGPU dialect

This is part of an on-going migration to adopt Properties inside MLIR.

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

Adopt Properties to store operations inherent Attributes in the Affine dialect

This is part of an on-going migration to adopt Properties inside MLIR.

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

[MachineLateInstrsCleanup] Bugfix for handling of kill flags.

With cb57b7a7, the kill flags are now tracked during the forward search over
the instructions and the call to findRegisterUseOperandIdx() should therefore
only check for killing uses.

As shown with the failing test CodeGen/Hexagon/vector-sint-to-fp.ll, it could
otherwise be the case that an undef use after the instruction that killed the
register will be inserted into MBBKills, and the kill flag will not be
cleared.

[MemProf] Control availability of hot/cold operator new from LTO link

Adds an LTO option to indicate that whether we are linking with an
allocator that supports hot/cold operator new interfaces. If not,
at the start of the LTO backends any existing memprof hot/cold
attributes are removed from the IR, and we also remove memprof metadata
so that post-LTO inlining doesn't add any new attributes.

This is done via setting a new flag in the module summary index. It is
important to communicate via the index to the LTO backends so that
distributed ThinLTO handles this correctly, as they are invoked by
separate clang processes and the combined index is how we communicate
information from the LTO link. Specifically, for distributed ThinLTO the
LTO related processes look like:
```
   # Thin link:
   $ lld --thinlto-index-only obj1.o ... objN.o -llib ...
   # ThinLTO backends:
   $ clang -x ir obj1.o -fthinlto-index=obj1.o.thinlto.bc -c -O2
   ...
   $ clang -x ir objN.o -fthinlto-index=objN.o.thinlto.bc -c -O2
```

It is during the thin link (lld --thinlto-index-only) that we have
visibility into linker dependences and want to be able to pass the new
option via -Wl,-supports-hot-cold-new. This will be recorded in the
summary indexes created for the distributed backend processes
(*.thinlto.bc) and queried from there, so that we don't need to know
during those individual clang backends what allocation library was
linked. Since in-process ThinLTO and regular LTO also use a combined
index, for consistency we query the flag out of the index in all LTO
backends.

Additionally, when the LTO option is disabled, exit early from the
MemProfContextDisambiguation handling performed during LTO, as this is
unnecessary.

Depends on D149117 and D149192.

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

[libc++][AIX] Remove LIBCXX-AIX-FIXME feature from test

This test was originally unsupported for `LIBCXX-AIX-FIXME` feature because we lacked `-fvisibility=hidden` support. AIX now has visibility support and the test passes in debug mode.

Reviewed By: #libc, Mordante

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

[Clang][BPF] Type print btf_type_tag properly

When running bcc tool execsnoop ([1]) which is built with latest llvm,
I hit the following error:
  $ sudo ./execsnoop.py
  /virtual/main.c:99:157: error: expected ')'
    data.ppid = ({ typeof(pid_t) _val; __builtin_memset(&_val, 0, sizeof(_val)); bpf_probe_read(&_val, sizeof(_val),
       (void *)&({ typeof(struct task_struct  btf_type_tag(rcu)*) _val; __builtin_memset(&_val, 0, sizeof(_val));
                                              ^
        bpf_probe_read(&_val, sizeof(_val), (void *)&task->real_parent); _val; })->tgid); _val; });

The failure reason is due to that the bcc rewriter printed type like
  struct task_struct  btf_type_tag(rcu)*
where the compiler cannot recognize what 'btf_type_tag(rcu)' is.

The above type is printed in [2] by UnaryOperator->getType().getAsString() (from clang)
in function ProbeVisitor::VisitUnaryOperator.

The original source type looks like ([3])
  struct task_struct {
    ...
    struct task_struct __rcu *real_parent;
    ...
  }
  where '__rcu' is a macro expanding to '__attribute__((btf_type_tag("rcu")))'.

Let us print btf_type_tag properly in clang so bcc tools and broader type printing
will work properly.

With this patch, the above rewrited source code looks like
    data.ppid = ({ typeof(pid_t) _val; __builtin_memset(&_val, 0, sizeof(_val)); bpf_probe_read(&_val, sizeof(_val),
       (void *)&({ typeof(struct task_struct  __attribute__((btf_type_tag("rcu")))*) _val; __builtin_memset(&_val, 0, sizeof(_val));
        bpf_probe_read(&_val, sizeof(_val), (void *)&task->real_parent); _val; })->tgid); _val; });

and execsnoop.py tool can run properly.

  [1] https://github.com/iovisor/bcc/blob/master/tools/exitsnoop.py
  [2] https://github.com/iovisor/bcc/blob/master/src/cc/frontends/clang/b_frontend_action.cc
  [3] https://github.com/torvalds/linux/blob/master/include/linux/sched.h

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

[X86] vector-reduce-or-bool.ll - add common AVX prefix

Share with AVX512 to reduce duplication

[Clang] Correctly handle allocation in template arguments

Fixes #62462

Reviewed By: #clang-language-wg, erichkeane

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

[TargetLowering] Fix unnecessary call to `computeKnownBits` (NFCI)

In the SimplifyDemandedBits function, there is a fallthrough to the
default case in the case of ISD::ADD, ISD::MUL and ISD::SUB. This
leads to a call to computeKnownBits which is unnecessary as the
calls to SimplifyDemandedBits in the cases themselves handle the
calculation of the known bits. This information is discarded through
the Known2 variables.

By keeping this information around and calling
KnownBits::mul or KnownBits::computeForAddSub directly, the
unnecessary computation can be avoided. For now, the NSW bit is not
passed through to KnownBits as this is something that
computeKnownBits does not handle either. This requires updating
computeForAddCarry to handle the flag as well.

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

[libc++][spaceship] Implement `operator<=>` for `array`

Implements part of P1614R2 "The Mothership has Landed"

Reviewed By: Mordante, #libc, philnik

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

[clang][dataflow] Remove deprecated pass-through APIs for DataflowAnalysisContext.

These were recently deprecated in https://reviews.llvm.org/D149464.

Reviewed By: ymandel, gribozavr2, xazax.hun

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

[Transform] Support more case for the transform pad operation

Don't choke on `outs` arguments that are not produced by `tensor.empty` or
`tensor.extract_slice`.

When the `outs` argument has a static shape we have all the necessary
information to proceed with the padding.

This makes the `transform.structured.pad` a little bit more resilient.

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

Revert "[mlir][mem2reg] Expose algorithm internals."

The commit causes build bot failures due to a missing dependencies:
https://buildkite.com/llvm-project/llvm-main/builds/7036#0187fb40-e4b6-4471-a2a0-2820b71c727b

This reverts commit 91cff8a71872cf49f0c5c9e5510f8065bfefa3c3.

Reapply [Coverity] Fix explicit null dereferences

This change fixes static code analysis errors

Reviewed By: skan

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

[X86] avx512-insert-extract.ll - add nounwind to silence cfi noise

[mlir][CallOpInterface] Add `setCalleeFromCallable` method

Currently `CallOpInterface` has a method `getCallableForCallee` to have a consistent way to get the callee from an operation with `CallOpInterface`, but missing a consistent way to set a callee for an operation with `CallOpInterface`.

A set callee method is useful for transformations that operate on `CallOpInterface`, and change the callee, e.g., a pass that specialize function, which clone the callee, and change the `CallOpInterface`'s callee to the cloned version. Without such method, transformation would need to understand the implementation for every operations with `CallOpInterface`, and have a type switch to handle them.

This review adds a method to set callee for operation with `CallOpInterface`.

Reviewed By: gysit, zero9178o

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

[libc++] Fix mistake in documentation of libcxx-lit script

[mlir][mem2reg] Expose algorithm internals.

This patch refactors the Mem2Reg infrastructure. It decouples
analysis from promotion, allowing for more control over the execution of
the logic. It also adjusts the interfaces to be less coupled to mem2reg
and more general. This will be useful for an upcoming revision
introducing generic SROA.

Reviewed By: gysit

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

[mlir][bytecode] Fix typo in DenseElementsAttr.

Was incorrectly marked as DenseIntElementsAttr (only used for
SparseElementsAttr).

[mlir] warn about passthrough in LLVM dialect doc

This mechanism has never been intended for anything but prototyping.

Adopt Properties to store operations inherent Attributes in the LLVM dialect

This is part of an on-going migration to adopt Properties inside MLIR.

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

Reland "Give NullabilityKind a printing operator<<"

This reverts commit 5326c9e480d70e16c2504cb5143524aff3ee2605.

The problem that caused the revert was downstream
(missing dep in user of clang).

Fix possible self assign issue for DIEValue

In DIEValue's operator assignment constructor, it didn't identify if
the two obj is the same.
I add code to identify them so that it will work correctly when we do
self assign here.

Reviewed By: skan

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

[PowerPC] Add target feature requirement to builtins

Clang has mechanism to specify required target features of a built-in
function. This patch adds such definitions to Altivec, VSX, HTM,
PairedVec and MMA builtins.

This will help frontend to detect incompatible target features of
bulitin when using target attribute syntax.

Reviewed By: nemanjai, kamaub

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

[clang-repl] Do not assert if we have weak references left.

Non-incremental Clang can also exit with the WeakRefReferences not empty upon
such example. This patch makes clang-repl consistent to what Clang does.

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

[JITLink][RISCV] Only generate PLT entries for external symbols

R_RISCV_CALL has been deprecated. [1] Both GCC and LLVM seem to not
generate it anymore and always use R_RISCV_CALL_PLT (even for calls that
do not need a PLT entry). Generating PLT entries based on relocation
type is not recommended and a better heuristic is to only generate them
when the target symbol is preemptable [2]. This patch implements this by
only generating PLT entries for undefined symbols.

[1] https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/340
[2] https://github.com/riscv-non-isa/riscv-elf-psabi-doc/issues/98

Reviewed By: lhames

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

[Clang][RISCV] Update vreinterpret.c test case with new script. NFC

[MLIR][Linalg] Rename `packElementWiseOp` to `packGenericOp` (NFC)

Commit b4563ee17ce45728a323c2708e549627b0a8ee9c enabled propagation for
pack and unpack through non-elementwise operations, update comments and
methods names to reflect the changes made.

Rework some tests where the `linalg.generic` was reading from
`tensor.empty`, which is undefined behaviour.

Reviewed By: hanchung, qedawkins

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

[NFC][ASAN] Sort includes

[NFC][ASAN] Add const to getter

[CodeGen][ShrinkWrap] Split restore point

Try to reland D42600

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

[test][lsan] Don't recompile the test

[test][sanitizer] Improve test expectation

Now we can fix sanitizers for the test one by one.

[test][sanitizer] Check pthread_create return value

[NFC][ASAN] Use alignof instead of constant

[NFC][ASAN] Extract ThreadRegistry initialization

[clang][dataflow][NFC] Remove `SkipPast` parameter from `getStorageLocation(const ValueDecl &).

This parameter was already a no-op, so removing it doesn't change behavior.

Depends On D149144

Reviewed By: ymandel, xazax.hun, gribozavr2

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

[MachineLateInstrsCleanup] Improve compile time for huge functions.

It was discovered that this pass could be slow on huge functions, meaning 20%
compile time instead of the usual ~0.5% (with a test case spending ~19 mins
just in the backend).

The problem related to the necessary clearing of earlier kill flags when a
redundant instruction is removed. With this patch, the handling of kill flags
is now done by maintaining a map instead of scanning backwards in the
function. This remedies the compile time on the huge file fully.

Reviewed By: vpykhtin, arsenm

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

Resolves https://github.com/llvm/llvm-project/issues/61397

[CodeGen] Autogen tests as prerequisite for D42600

Autogenerating tests as suggested in D42600

[RISCV] Add MC support of RISCV zcmp Extension

This patch add the instructions of zcmp extension.

Instructions in zcmp extension try to optimise `mv` inst and the prologue & epilogue in functions

co-author: @Scott Egerton, @ZirconLiu, @Lukacma, @Heda Chen, @luxufan, @heyiliang, @liaochunyu

Reviewed By: craig.topper

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

[NFC][ASAN] Reformat the file

Revert "[InstCombine] Improve bswap + logic_op optimization"

The generic cast to `BinaryOperator` can break if `V` is not a
`BinaryOperator` (i.e a `ConstantExpr`). This occurs in things like
PPC linux build.

This reverts commit fe733f54da6faca95070b36b1640dbca3e43d396.

[gn build] Port 8d657c461a5a

[X86][AsmParser] Refactor code in AsmParser

1. Share code `optimizeInstFromVEX3ToVEX2` with MCInstLower
2. Move the code of optimization for shift/rotate to a separate file

Reviewed By: craig.topper

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

[SCEV][reland] More precise trip multiples

We currently have getMinTrailingZeros(), from which we can get a SCEV's
multiple by computing 1 << MinTrailingZeroes. However, this only gets us
multiples that are a power of 2. This patch introduces a way to get max
constant multiples that are not just a power of 2. The logic is similar
to that of getMinTrailingZeros. getMinTrailingZerosImpl is replaced by
computing the max constant multiple, and counting the number of trailing
bits.

I have so far found this useful in two places:

1) Computing unsigned constant ranges. For example, if we have i8
   {10,+,10}<nuw>, we know the max constant it can be is 250.

2) My original intent was to use this in getSmallConstantTripMultiples,
   but it has no effect right now due to change from D110587. For
   example, if we have backedge count `(6 * %N) - 1`, the trip count
   becomes `1 + zext((6 * %N) - 1)`, and we cannot say that 6 is a
   multiple of the SCEV. I plan to look further into this separately.

The implementation assumes the value is unsigned. It can probably be
extended to handle signed values as well.

If the code sees that a SCEV does not have <nuw>, it will fall back to
finding the max multiple that is a power of 2. Multiples that are a
power of 2 will still be a multiple even after the SCEV overflows. This
does not apply to other values. This is the 1st commit message:

---

This relands https://reviews.llvm.org/D141823. The verification fails
when expensive checks are turned on. This can occur when:

1. SCEV S's multiple is cached
2. SCEV S's no wrap flags are strengthened, and the multiple changes
3. SCEV verifier finds that S's cached and recomputed multiple are
   different

We eliminate most cases by forgetting SCEVAddRecExpr's cached values
when the flags are modified, but there are still cases for other SCEV
types. We relax the check by making sure the cached multiple divides the
recomputed multiple, ensuring the cached multiple is correct,
conservative multiple.

Reviewed By: mkazantsev

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

[DWARF][MC] improve the error message when DwarfLineStrSection is null.

Summary: Currently the crush info is ambiguous when DwarfLineStrSection is null. The patch adds an assertion in the constructor of MCDwarfLineStr when DwarfLineStrSection is null.

Reviewed By: shchenz

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

[MC][ARM] Fix redundant errors for .quad/.8byte relocations on ELF

For a .quad/.8byte directive that needs a relocation, Mach-O emits one error
while ELF emits two. Emit just one for ELF and change the diagnostic to match
other ports.

[MC] x86-32: properly report error for .quad relocation

Fix a llvm_unreachable crash in -DLLVM_ENABLE_ASSERTIONS=on builds and
possible accept-invalid in -DLLVM_ENABLE_ASSERTIONS=off builds.

[LoongArch] Add some comments to getBPReg. NFC

[DWARFLinker] Remove an unused raw_svector_ostream

MCDwarfFrameEmitter::EncodeAdvanceLoc: use SmallVectorImpl instead of raw_ostream. NFC

Similar to 49488490d195591bfc90daef111cd7293f8c80aa.
Remove MCDwarfFrameEmitter::EmitAdvanceLoc which is only called once.

[gn build] Port 746cf7e38cc4

[libc++] Use the __is_trivially_equality_comparable builtin

Reviewed By: ldionne, #libc

Spies: libcxx-commits

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

[libc++][Modules] Add missing includes and exports

Several headers are missing includes for things they use.

type_traits.is_enum needs to export type_traits.integral_constant so that clients can access its `value` member without explicitly including __type_traits/integral_constant.h themselves.

Make `subrange_fwd` a peer submodule to `subrange` rather than a submodule of it, and have `subrange` export `subrange_fwd`. That will make it easier to programmatically generate modules for the private detail headers, and it will accomplish the same effect that __ranges/subrange.h will make subrange_kind visible.

Reviewed By: Mordante, #libc

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

[libc++] test/libcxx/transitive_includes.sh.cpp dumps loads of unhelpful preprocessor output when it fails

Send stdout to dev/null since the preprocessor output isn't relevant to the test and is tons of noise when the test fails.

Reviewed By: Mordante, #libc, philnik

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

Reland D147524 "[LoongArch] Provide basic TargetTransformInfo implementation"

This patch only provides basic LoongArchTTIImpl, and more hooks
will be added to provide TTI machinery for LoongArch soon.

Reviewed By: SixWeining, xen0n

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

Revert "[LoongArch] Provide basic TargetTransformInfo implementation"

This reverts commit 040a41a852933d3d1b855aebc8b054baa60f61e2.

Author name is wrong.

[libc] Use Linux errno and signal strings for Fuchsia

The exact set of supported values is determined by the <errno.h>
and <signal.h> headers, which don't (yet) come from llvm-libc on
Fuchsia. The mappings of SIG* and E* codes to psignal/strsignal
and perror/strerror text used in Fuchsia libc today is the same
as for Linux.

Reviewed By: abrachet

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

[KnownBits] Improve `KnownBits::rem(X, Y)` in cases where we can deduce low-bits of output

The first `cttz(Y)` bits in `X` are translated 1-1 in the output.

Alive2 Links:
    https://alive2.llvm.org/ce/z/Qc47p7
    https://alive2.llvm.org/ce/z/19ut5H

Reviewed By: RKSimon

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

[KnownBits] Add tests for getting lowbits of `rem X, Y`; NFC

Reviewed By: foad

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

[X86] Lower used `(atomicrmw xor p, SignBit)` as `(atomicrmw add p, SignBit)`

`(xor X, SignBit)` == `(add X, SignBit)`. For atomics whose result is
used, the `add` option is preferable because of the `xadd` instruction
which allows us to avoid either a CAS loop or a `btc; setcc; shl`.

Reviewed By: RKSimon

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

[X86] Add tests for `(atomicrmw xor p, Imm)`; NFC

Reviewed By: RKSimon

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

Revert "[clang] Make predefined expressions string literals under -fms-extensions"

This reverts commit 856f384bf94513c89e754906b7d80fbe5377ab53.

Breaks bots, e.g. https://lab.llvm.org/buildbot/#/builders/123/builds/18775

Revert "[AArch64] Emit FNMADD instead of FNEG(FMADD)"

This reverts commit ea228bd0bd0173ffd4aac497a312a852e8f7ffad.

Cuases a crash on AArch64. Testcase provided at D149260.

[MC] MCDwarfLineAddr::Encode: use SmallVectorImpl instead of raw_ostream. NFC

Similar to D145791: most call sites need a SmallString, but have to provide a
raw_svector_ostream wrapper with unneeded abstraction and overhead:

raw_ostream::write =(inlinable)=> flush_tied_then_write (unneeded TiedStream check) =(virtual function call)=> raw_svector_ostream::write_impl ==> SmallVector append(ItTy in_start, ItTy in_end) (range; less efficient then push_back).

Just use SmallVectorImpl to simplify and optimize code. Unfortunately most call
sites use SmallString, so we have to use SmallVectorImpl<char> instead of
<uint8_t> to avoid large refactoring.

[NFC][HWASAN] Add more pthread interceptors

They are empty for now. Follow up patches will introduce behaviour
changes.

[NFC][LSAN] Add more pthread interceptors

They are empty for now. Follow up patches will introduce behaviour
changes.

[NFC][ASAN] Add more pthread interceptors

They are empty for now. Follow up patches will introduce behaviour
changes.

[NFC][HWASAN] Fix mutex in thread safety annotation

[NFC][HWASAN] Reformat InitializeInterceptors

[test][sanitizer] Extend the test

Add pthread_exit and pthread_attr_setdetachstate.

[NFC][AArch64][GlobalISel] Add a gisel run line for shift-logic.ll

[RISCV] Use inheritance instead of nesting multiclass instantiaions. NFC

[RISCV] Ues PatGpr to reduce some tablegen code. NFC

[DAG] Calculate the number of sign bits for constant BUILD_VECTOR directly.

For constant BUILD_VECTORs the operands need to be legal types. This can mean
that when the number of sign bits is calculated it may look that the entire
constant and inefficiently produce less sign bits than it could. For example i8
vectors could use i32 elements, for which 0x000000ff would be incorrectly
limited to 1 sign bit as the original value has 24 sign bits. This makes it
look at the constant directly, truncated to the correct type for the element so
that it can correctly return 8.

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

[X86] lowerShuffleAsElementInsertion - fold to or(vzext_movl(scalar_to_vector(zext(x))), and(constant, mask))

The logic in this function is a bit of a mess, but masking a vector constant should allow us to OR the zero-extended i8/i16 scalar value in place.

We can do more here - reusing the OR pattern if the relevant unused elements are known zero etc. but this is enough to address a regression from D127115.

ObjectFile: introduce a COFF object file plugin

Windows uses COFF as an object file format and PE/COFF as an executable
file format. They are subtly different and certain elements of a COFF
file may not be present in an executable. Introduce a new plugin to add
support for the COFF object file format which is required to support
loading of modules built with -gmodules. This is motivated by Swift
which serialises debugging information into a PCM which is a COFF object
file.

Differential Revision: https://reviews.llvm.org/D149987
Reviewed By: bulbazord