[llmv-pdbutil] Replace ExitOnError with explicit error handling.

At Sony we are developing llvm-dva

https://lists.llvm.org/pipermail/llvm-dev/2020-August/144174.html

For its PDB support, it requires functionality already present
in llvm-pdbutil.

We intend to move that functionaly into the PDB library to be
shared by both tools. That change will be done in 2 steps, that
will be submitted as 2 patches:

(1) Replace 'ExitOnError' with explicit error handling.
(2) Move the intended shared code to the PDB library.

This patch is for step (1).

As 'ExitOnError' is intended to be used only in tool code, replace
all occurrences in the code that will be moved to the PDB library
with explicit error handling.

Reviewed By: aganea, dblaikie, rnk

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

[IROutliner] Do not outlined from functions with optnone

Since the IROutliner is performing an optimization, it should not outline from functions explicitly marked with optnone. This adds an extra check and test to make sure this does not occur.

Reviewers: paquette

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

[X86][NFC] Run clang-format on cb26730aaa8b, fix typo and remove redundant else

[X86][NFC] Unify implementations of getting condition code

[mlir][Arith] Add constant folder for right shift

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

[Analysis] Apply clang-tidy fixes for readability-redundant-smartptr-get (NFC)

[LV] Remove dead Loop argument from emitMemRuntimeChecks. (NFC)

[SLP] Explicit track required stacksave/alloca dependency

The semantics of an inalloca alloca instruction requires that it not be reordered with a preceeding stacksave intrinsic call.  Unfortunately, there's no def/use edge or memory dependence edge.  (THe memory point is slightly subtle, but in general a new allocation can't alias with a call which executes strictly before it comes into existance.)

I'd tried to tackle this same case previously in 689babdf6, but the fix chosen there turned out to be incomplete.  As such, this change contains a fully revert of the first fix attempt.

This was noticed when investigating problems which surfaced with D118538, but this is definitely an existing bug.  This time around, I managed to reduce a couple of additional cases, including one which was being actively miscompiled even without the new scheduling change.  (See test diffs)

Compile time wise, we only spend extra time when seeing a stacksave (rare), and even then we walk the block at most once per schedule window extension.  Likely a non-issue.

[PPCISelLowering] Avoid emitting calls to __multi3, __muloti4

After D108936, @llvm.smul.with.overflow.i64 was lowered to __multi3
instead of __mulodi4, which also doesn't exist on PowerPC 32-bit, not
even with compiler-rt. Block it as well so that we get inline code.

Because libgcc doesn't have __muloti4, we block that as well.

Fixes #54460.

Reviewed By: craig.topper

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

[Transform] Apply clang-tidy fixes for readability-redundant-smartptr-get (NFC)

[libc++][test][NFC] Remove libcpp-no-concepts.

This is no longer needed.

Reviewed By: #libc, philnik

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

[PowerPC][NFC] use right hardware loop intrinsics in test case

[XCOFF] support XCOFFObjectWriter for fileHeader and sectionHeaders in 64-bit XCOFF.

This is the first patch to enable the XCOFF64 object writer.
Currently only fileHeader and sectionHeaders are supported.

Reviewed By: jhenderson, DiggerLin

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

[MLIR][Presburger] remove redundant constraints in coalesce

This patch improves the representation size of individual
`IntegerRelation`s by calling the function
`IntegerRelation::removeRedundantConstraints`. While this is only a
slight optimization in the current version, it will be necessary for
patches to come.

Reviewed By: arjunp

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

enable binop identity constant folds for add

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

[X86] Simplify function isDataInvariant by using X86MnemonicTables

This is not a NFC change b/c we add more instructions like
IMUL16/32/64r, MOV16ao16 and MOV16rr_REV etc to the list.
But I think it's reasonable.

Reviewed By: Amir

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

[VPlan] Add test for VPExpandSCEVRecipe printing.

[X86] Add test add with bit0 extraction and improve comments

Based on feedback from D122084

[X86] combineAddOrSubToADCOrSBB - split to more cleanly handle commuted variants.

Split combineAddOrSubToADCOrSBB into wrapper (which handles ADDs with commuted args) and the real combine, which no longer has to account for commutation.

I'm intending to extend combineAddOrSubToADCOrSBB to detect patterns other than just X86ISD::SETCC, so we need to detect all patterns without detecting them as part of a commutation swap.

[X86][NFC] Generate fields and getters for subtarget features

Non-duplicated comments are moved from X86Subtarget.h to X86.td.
This is a follow-up patch for D120906.

[trace][intelpt] Instruction count in trace info

Added a line to `thread trace dump info` results which shows total number of instructions executed until now.

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

[X86][NFC] Remove unused variable UseAA

[X86][NFC] Remove unused feature UseAA

[X86][NFC] Rename hasCMOV() to canUseCMOV(), hasLAHFSAHF() to canUseLAHFSAHF()

To make them less like other feature functions.
This is a follow-up patch for D121978.

[SelectionDAG][RISCV] Make RegsForValue::getCopyToRegs explicitly zero_extend constants.

ComputePHILiveOutRegInfo assumes that constant incoming values to
Phis will be zero extended if they aren't a legal type. To guarantee
that we should zero_extend rather than any_extend constants.

This fixes a bug for RISCV where any_extend of constants can be
treated as a sign_extend.

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

[RISCV] Add test case for miscompile caused by treating ANY_EXTEND of constants as SIGN_EXTEND.

The code that inserts AssertZExt based on predecessor information assumes
constants are zero extended for phi incoming values this allows
AssertZExt to be created in blocks consuming a Phi.
SelectionDAG::getNode treats any_extend of i32 constants as sext for RISCV.
The code that creates phi incoming values in the predecessors creates an
any_extend for the constants which then gets treated as a sext by getNode.
This makes the AssertZExt incorrect and can cause zexts to be
incorrectly removed.

This bug was introduced by D105918

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

[slp,tests] Consolidate two test files into one

There are some slight changes to the test lines due to different cost threshold choices in the two command lines, but I don't believe these to be interesting the purpose of the tests.

[bazel][mlir] Add MLIR PDLL LSP server target

Add targets for PDLL LSP server.

[tests, SLP] Add coverage for missing dependencies for stacksave intrinsics

The existing scheduling doesn't account for the scheduling restrictions implied by inalloca allocas combined with stacksave/stackrestore.  This adds coverage including one currently miscompiling case.

Revert "[amdgpu][nfc] Pass function instead of module to allocateModuleLDSGlobal"
Reconsidered, better to handle per-function state in the constructor as before.
This reverts commit 98e474c1b3210d90e313457bf6a6e39a7edb4d2b.

mlir: set CMAKE_INCLUDE_CURRENT_DIR to fix out-of-tree builds

This option tells CMake to add current source and binary
directories to the include path for each directory[1].

Required include directories from build tree (for generated
files) were previously added in `mlir_tablegen` but this was
changed in 03078ec20b12605fd4dfd9fe9c98a26c9d2286d7 .

These are still needed, however, for out-of-tree builds
that don't build as part of LLVM (via LLVM_ENABLE_PROJECTS).
Building as part of LLVM works regardless, AFAICT,
because LLVM sets this option and so the MLIR build inherits it.

FWIW, various other (in-tree) LLVM projects set this as well.

And of course this fixes the out-of-tree
mlir-by-itself build scenario I'm using.

[1] https://cmake.org/cmake/help/latest/variable/CMAKE_INCLUDE_CURRENT_DIR.html

Reviewed By: mehdi_amini

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

[mlir:PDLL][NFC] Remove a dead comment about constant params

These were removed, and the FIXME is no longer relevant.

[SLP] Respect control dependence within a block during scheduling

This fixes an active miscompile visible in the test changes.  The basic problem is that the scheduling dependency graph didn't have any edges for control dependence within a single basic block.  The result is that we could (and in some rare cases *did*) perform reorderings within a block which could introduce new undefined behavior along paths which didn't previously contain any.

Impact wise, we have two major cases where control is not guaranteed to reach a later instruction in the block: may throw calls, and calls containing infinite loops.
* The former case was mostly covered by the memory dependencies, and to trigger require a function which can throw, but not write to memory.  In theory, such a case is possible, but not likely in practice.
* The later case is likely more of an issue in practice.  After this code was first written, we changed the IR semantics to allow well defined infinite loops without satisifying mustprogress.  Even for C/C++ - which do imply mustprogress - recent changes to how we treat atomics (e.g. an atomic read does not always imply a write) could expose this issue.  I'm a bit shocked we don't seem to have a bug report which hit this in real code actually.

Compile time wise, this results in a single extra scan of the scheduling window in the common case.  Since we stop scanning at the next instruction which isn't guaranteed to execute, no matter what order we traverse instructions in, we scan the block once.  The exception to this is that when we extend the scheduling window downwards, we invalidate all dependencies, and thus rescan.  So the potentially expensive case is when we a call in a big schedule window which is frequently extended.  We could optimize this case (by caching the last instruction not guaranteeed to transfer execution and scanning only the extended window) and starting there), but I decided to leave the complexity until it mattered.  That same case is already degenerate with memory dependences which is more expensive than the control dependence scan.

We could also consider combining the memory dependence and control dependence sets to reduce memory usage, but since it complicates the code slightly and makes debugging a bit harder, I went with the simplest scheme for now.

This was noticed while trying to understand the failures reported against D118538, but is not otherwise related to that change.

[libSupport] make CallBacksToRun static local

In order to allow compiling with -Werror=global-constructors with c++20 and above.

Discussion: https://discourse.llvm.org/t/llvm-lib-support-signals-cpp-fails-to-compile-due-to-werror-global-constructors/61070

Reviewed By: mehdi_amini

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

[mlir:PDL] Remove the ConstantParams support from native Constraints/Rewrites

This support has never really worked well, and is incredibly clunky to
use (it effectively creates two argument APIs), and clunky to generate (it isn't
clear how we should actually expose this from PDL frontends). Treating these
as just attribute arguments is much much cleaner in every aspect of the stack.
If we need to optimize lots of constant parameters, it would be better to
investigate internal representation optimizations (e.g. batch attribute creation),
that do not affect the user (we want a clean external API).

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

[mlir][PDLL] Add signature help to the PDLL language server

This commit adds signature support to the language server,
and initially supports providing help for: operation operands and results,
and constraint/rewrite calls.

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

[mlir][PDLL] Add code completion to the PDLL language server

This commit adds code completion support to the language server,
and initially supports providing completions for: Member access,
attributes/constraint/dialect/operation names, and pattern metadata.

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

[mlir][PDLL] Add symbol support to the PDLL language server

This adds support for documenting the top-level "symbols",
e.g. patterns, constraints, rewrites, etc., within a PDLL file.

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

[mlir][PDLL] Add hover support to the PDLL language server

This adds support for providing information when hovering over
operation names, variables, patters, constraints, and rewrites.

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

[mlir][PDLL] Add an initial language server for PDLL

This commits adds a basic language server for PDLL to enable providing
language features in IDEs such as VSCode. This initial commit only
adds support for tracking definitions, references, and diagnostics, but
followup commits will build upon this to provide more significant behavior.

In addition to the server, this commit also updates mlir-vscode to support
the PDLL language and invoke the server.

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

[LV] Remove unnecessary uses of Loop* (NFC).

Update functions that previously took a loop pointer but only to get the
pre-header. Instead, pass the block directly. This removes the
requirement for the loop object to be created up-front.

[X86] Rename FeatureCMPXCHG8B/FeatureCMPXCHG16B to FeatureCX8/CX16 to match CPUID.

Rename hasCMPXCHG16B() to canUseCMPXCHG16B() to make it less like other
feature functions. Add a similar canUseCMPXCHG8B() that aliases
hasCX8() to keep similar naming.

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

[X86] Add some initial test coverage for PR35908 add/sub + bittest patterns

[OpenMP][FIX] Do not crash when kernels are debug wrapper functions

With debug information enabled (-g) Clang will wrap the actual target
region into a new function which is called from the "kernel". The problem
is that the "kernel" is now basically a wrapper without all the things
we expect. More importantly, if we end up asking for an AAKernelInfo
for the "target region function" we might try to turn it into SPMD mode.
That used to cause an assertion as that function doesn't have an
appropriately named `_exec_mode` global. While the global is going away
soon we still need to make sure to properly handle this case, e.g.,
perform optimizations reliably.

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

[docs] Fix a couple of typos

Signed-off-by: Itay Bookstein <ibookstein@gmail.com>

[X86] combineAddOrSubToADCOrSBB - pull out repeated Y.getOperand(1) calls. NFC.

[libc++] Prepare string tests for constexpr

These are the last™ changes to the tests for constexpr preparation.

Reviewed By: Quuxplusone, #libc, Mordante

Spies: Mordante, EricWF, libcxx-commits

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

[docs] Fixed minor ordering issue

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

[X86] createShuffleMaskFromVSELECT - handle BLENDV constant masks as well as VSELECT constant masks

Handle constant masks for both vselect nodes (mask != 0) and blendv nodes (mask < 0)

[SLP,tests] Add coverage showing need for control dependencies during scheduling

[amdgpu][nfc] Pass function instead of module to allocateModuleLDSGlobal

[X86] combineSelect - don't constant fold BLENDV nodes like VSELECT

If a X86ISD::BLENDV op appears before legalization (in this test case due to the icmp_slt x, 0) its constant mask was being treated as a vselect mask (mask != 0) instead of blendv (mask < 0)

This just prevents constant folding entirely for non-VSELECT ops.

[X86] Add test showing a bug where a BLENDV mask is being constant folded as VSELECT mask

combineSelect doesn't expect X86ISD::BLENDV ops to appear before legalization and is treating the constant mask as a vselect mask (mask != 0) instead of blendv (mask < 0)

[VPlan] Improve pattern in vplan-printing.ll check line.

The existing pattern only matched a single value, which breaks if the
numbering slightly changes.

[X86] Update remaining AVX512 VBMI2 VL intrinsic tests to avoid adds

As noticed in D119654, by adding the masked intrinsics results together we can end up with the selects being canonicalized away from the intrinsic - this isn't what we want to test here so replace with a insertvalue chain into a aggregate instead to retain all the results.

[X86] LowerAndToBT - fold BT(NOT(X),Y) -> BT(X,Y) and flip the CondCode

[X86][SSE] Add initial support for extracting non-constant bool vector elements

We can use MOVMSK+TEST/BT to extract individual bool elements even if the index isn't constant

This relies on combineBitcastvxi1 so some AVX512 cases still aren't optimized as they avoid MOVMSK usage.

[X86][SSE] Add tests for non-constant bool vector extractions

We should be able to perform this with MOVMSK+TEST/BT instead of spilling to stack

[AArch64] Combine ISD::SETCC into AArch64ISD::ANDS

When N > 12, (2^N -1) is not a legal add immediate (isLegalAddImmediate will return false).
ANd if SetCC input use this number, DAG combiner will generate one more SRL instruction.
So combine [setcc (srl x, imm), 0, ne] to [setcc (and x, (-1 << imm)), 0, ne] to get better optimization in emitComparison
Fix https://github.com/llvm/llvm-project/issues/54283

Reviewed By: paulwalker-arm

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

[AArch64] Fix incorrect getSetCCInverse usage within trySwapVSelectOperands.

When inverting the compare predicate trySwapVSelectOperands is
incorrectly using the type of the select's cond operand rather
than the type of cond's operands. This means we're treating all
inversions as if they're integer.

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

[libc++][test] Improves handle formatter.

Before it only accepted one output iterator type. Now it accepts all
output iterator types as required by BasicFormatter.

Reviewed By: #libc, ldionne

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

[NFC] Remove unused parameters for SubtargetEmitter::ParseFeaturesFunction

[trace][intelpt][docs] Added intel-pt build instructions for lldb

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

[Xcore] Set Int_MemBarrier as a meta-instruction

Reviewed By: nigelp-xmos

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

[SelectionDAG] Use APInt::zextOrSelf instead of zextOrTrunc in ComputePHILiveOutRegInfo

The width never decreases here.

Add DXIL triple

This patch adds triple support for:

* dxil architecture
* shadermodel OS (with version parsing)
* shader stages as environment

Reviewed By: MaskRay, pete

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

[lldb/test] Fix typo in eventlistener.py (NFC)

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>

[CMake] Update cache file for Win to ARM Linux cross toolchain builders. NFC.

* fixed remote test script arguments for libc++/compiler-rt libraries.
* disabled shared libc++abi libraries (to let remote tests get passed).

[MLIR][SCF] Place hoisted scf.if->select prior to the remaining if

This patch slightly updates the behavior of scf.if->select to
place any hoisted select statements prior to the remaining scf.if body.

This allows better composition with other canonicalization passes, such as
scf.if nested merging.

Reviewed By: ftynse

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

Ensure that APIRecords get destroyed correctly.

Implements an APISet specific unique ptr type that has a custom deleter
that just calls the underlying APIRecord subclass destructor.

[flang] Error recovery improvement in runtime (IOMSG=)

Some refactoring and related fixes for more accurate
user program error recovery in the I/O runtime, especially
for error recovery with IOMSG= character values.

1) Move any work in an EndIoStatement() implementation
that may raise an error into a new CompleteOperation()
member function.  This allows error handling APIs like
GetIoMsg() to complete a pending I/O statement and harvest
any errors that may result.

2) Move the pending error code from ErroneousIoStatementState
to a new pendingError_ data member in IoErrorHandler.
This allows IoErrorHandler::InError() to return a correct
result when there is a pending error that will be recovered
from so that I/O list data transfers don't crash in the meantime.

3) Don't create and leak a unit for a failed OPEN(NEWUNIT=n)
with error recovery, and don't modify 'n'.  (Depends on
changes to API call ordering in lowering, in a separate patch;
code was added to ensure that OPEN statement control list
specifiers, e.g. SetFile(), must be passed before GetNewUnit().)

4) Fix the code that calls a form of strerror to fill an
IOMSG= variable so that it actually works for Fortran's
character type: blank fill with no null or newline termination.

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

[flang] Accept legacy aliases for intrinsic function names

Support the names AND, OR, and XOR for the generic intrinsic
functions IAND, IOR, and IEOR respectively.

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

[flang] Convert RUNTIME_CHECK to better error for user errors in transformational.cpp

In flang/runtime/transformational.cpp, there are many RUNTIME_CHECK assertions
for errors that should have been caught in semantics, but there are alno others
that signify program errors that in principle cannot be detected until
execution.  Convert this second group into readable fatal error messages.
Also clean up some missing braces and incorrect printf formats found
along the way.

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

[lldb/test] Add events listener helper class to lldbtest

This patch introduces a generic helper class that will listen for
event in a background thread and match it against a source broadcaster.

If the event received matches the source broadcaster, the event is
queued up in a list that the user can access later on.

The motivation behind this is to easily test new kinds of events
(i.e. Swift type-system progress events). However, this patch also
updates `TestProgressReporting.py` and `TestDiagnosticReporting.py`
to make use of this new helper class.

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

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>

[flang] Add explanatory messages to grammar for language extensions

Extend "extension<LanguageFeature>()" to incorporate an explanatory
message better than the current generic "nonstandard usage:".

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

[ARM] Fix shouldExpandAtomicLoadInIR for subtargets without ldrexd.

Regression from 2f497ec3; we should not try to generate ldrexd on
targets that don't have it.

Also, while I'm here, fix shouldExpandAtomicStoreInIR, for consistency.
That doesn't really have any practical effect, though.  On Thumb targets
where we need to use __sync_* libcalls, there is no libcall for stores,
so SelectionDAG calls __sync_lock_test_and_set_8 anyway.

Autogenerate llvm/test/CodeGen/ARM/atomic-load-store.ll

[slp][tests] Add missing function attributes

SLP is currently assuming that control dependence in these cases is irrelevant.  This is only valid if none of the lib-funcs involved can throw or infinite loop in the scalar forms.  This appears to be true (or at least we infer the respective attributes) for the libfuncs I spot checked.  This change is mostly for shrunking the diff on an upcoming patch.

[mlir] Remove incorrect builders for ExpandShapeOp

ExpandShapeOp builder cannot infer the result type since it doesn't know
how the dimension needs to be split. Remove this builder so that it
doesn't get used accidently. Also remove one potential path using it in
generic fusion.

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

[AMDGPU] Add gfx940 run line to gfx90a mfma test. NFC.

[X86] Adjust tests to run on gfni capable cpu levels

AVX512BWVL capable cpus are required 512-bit gfni

[X86] Fix typo in gfni funnel shift test

We already have rotation coverage

[GlobalOpt] Don't replace alias with aliasee if either alias/aliasee may be preemptible

Generalize D99629 for ELF. A default visibility non-local symbol is preemptible
in a -shared link. `isInterposable` is an insufficient condition.

Moreover, a non-preemptible alias may be referenced in a sub constant expression
which intends to lower to a PC-relative relocation. Replacing the alias with a
preemptible aliasee may introduce a linker error.

Respect dso_preemptable and suppress optimization to fix the abose issues. With
the change, `alias = 345` will not be rewritten to use aliasee in a `-fpic`
compile.
```
int aliasee;
extern int alias __attribute__((alias("aliasee"), visibility("hidden")));
void foo() { alias = 345; } // intended to access the local copy
```

While here, refine the condition for the alias as well.

For some binary formats like COFF, `isInterposable` is a sufficient condition.
But I think canonicalization for the changed case has little advantage, so I
don't bother to add the `Triple(M.getTargetTriple()).isOSBinFormatELF()` or
`getPICLevel/getPIELevel` complexity.

For instrumentations, it's recommended not to create aliases that refer to
globals that have a weak linkage or is preemptible. However, the following is
supported and the IR needs to handle such cases.
```
int aliasee __attribute__((weak));
extern int alias __attribute__((alias("aliasee")));
```

There are other places where GlobalAlias isInterposable usage may need to be
fixed.

Reviewed By: rnk

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

[NewPM] Don't skip SCCs not in current RefSCC

With D107249 I saw huge compile time regressions on a module (150s ->
5700s). This turned out to be due to a huge RefSCC in
the module. As we ran the function simplification pipeline on functions
in the SCCs in the RefSCC, some of those SCCs would be split out to
their RefSCC, a child of the current RefSCC. We'd skip the remaining
SCCs in the huge RefSCC because the current RefSCC is now the RefSCC
just split out, then revisit the original huge RefSCC from the
beginning.  This happened many times because many functions in the
RefSCC were optimizable to the point of becoming their own RefSCC.

This patch makes it so we don't skip SCCs not in the current RefSCC so
that we split out all the child RefSCCs on the first iteration of
RefSCC. When we split out a RefSCC, we invalidate the original RefSCC
and add the remainder of the SCCs into a new RefSCC in
RCWorklist. This happens repeatedly until we finish visiting all
SCCs, at which point there is only one valid RefSCC in
RCWorklist from the original RefSCC containing all the SCCs that
were not split out, and we visit that.

For example, in the newly added test cgscc-refscc-mutation-order.ll,
we'd previously run instcombine in this order:
f1, f2, f1, f3, f1, f4, f1

Now it's:
f1, f2, f3, f4, f1

This can cause more passes to be run in some specific cases,
e.g. if f1<->f2 gets optimized to f1<-f2, we'd previously run f1, f2;
now we run f1, f2, f2.

This improves kimwitu++ compile times by a lot (12-15% for various -O3 configs):
https://llvm-compile-time-tracker.com/compare.php?from=2371c5a0e06d22b48da0427cebaf53a5e5c54635&to=00908f1d67400cab1ad7bcd7cacc7558d1672e97&stat=instructions

Reviewed By: asbirlea

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

[RGT] StencilTest: Fix an assertion

ASSERT_THAT_EXPECTED implicitly calls takeError(), and calling
takeError() a second time returns nothing, so the check for the
content of the error text wasn't being executed.
Fixes Issue #48901

Found by the Rotten Green Tests project.

[OpenMP] Initial parsing/sema for the 'omp target teams loop' construct

 Adds basic parsing/sema/serialization support for the
 #pragma omp target teams loop directive.

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

Fix computation of MadeChange bit in AtomicExpandPass.

Fixes llvm-clang-x86_64-expensive-checks-debian failure with 2f497ec3.

expandAtomicStore always modifies the function, so make sure we set
MadeChange unconditionally. Not sure how nobody else has stumbled over
this before.

Driver: Make macOS the default target OS for -arch arm64

This is a follow up to 565603cc94d79a8d0de6df840fd53714899fb890,
which made macOS the default target OS for `-arch arm64` when
running on an Apple Silicon Mac. Now it'll be the default when
running on an Intel Mac too.

clang/test/Driver/apple-arm64-arch.c was a bit odd before: it was added
for the above commit, but tested the inverse behaviour and XFAIL'ed on
Apple Silicon. This inverts it to the (new) behaviour (that's now
correct regardless) and removes the XFAIL.

Radar-Id: rdar://90500294

[AMDGPU] Added gfx940 mfma dst constraint test. NFC.

[AMDGPU] gfx940 basic speed model

This is incomplete and will handle more instructions as they are added.

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

[AMDGPU] Disable some MFMA instructions on gfx940

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

Update llvm-config.h.cmake for 7b983917d4

[AMDGPU] reuse blgp as neg in 2 mfma operations on gfx940

GFX940 repurposes BLGP as NEG only in DGEMM MFMA.

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

[scudo] Fix static and unused function type annotations

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

[scudo] Don't assume preprocessor macro is defined

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

[ARM] Fix ARM backend to correctly use atomic expansion routines.

Without this patch, clang would generate calls to __sync_* routines on
targets where it does not make sense; we can't assume the routines exist
on unknown targets. Linux has special implementations of the routines
that work on old ARM targets; other targets have no such routines. In
general, atomics operations which aren't natively supported should go
through libatomic (__atomic_*) APIs, which can support arbitrary atomics
through locks.

ARM targets older than v6, where this patch makes a difference, are rare
in practice, but not completely extinct. See, for example, discussion on
D116088.

This also affects Cortex-M0, but I don't think __sync_* routines
actually exist in any Cortex-M0 libraries. So in practice this just
leads to a slightly different linker error for those cases, I think.

Mechanically, this patch does the following:

- Ensures we run atomic expansion unconditionally; it never makes sense to
completely skip it.
- Fixes getMaxAtomicSizeInBitsSupported() so it returns an appropriate
number on all ARM subtargets.
- Fixes shouldExpandAtomicRMWInIR() and shouldExpandAtomicCmpXchgInIR() to
correctly handle subtargets that don't have atomic instructions.

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

Reland "[gn build] (manually) port 6316129e066e"

This reverts commit 21b97df74c15aa29a9d5ca54e3033eae6c97362d.
6316129e066e relanded in 7b983917d455.

[libc++] Enable modernize-loop-convert

Reviewed By: ldionne, Mordante, #libc

Spies: var-const, aheejin, libcxx-commits

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

[polly] Fix NPM unittests after D121566.

Add a cmake flag to turn `llvm_unreachable()` into builtin_trap() when assertions are disabled

This re-lands 6316129e066e after fixing the condition logic.

The new flag seems to not be working yet on Windows, where the builtin
trap isn't "no return".

Reviewed By: dexonsmith

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