[ValueTracking] Slightly clean up programUndefinedIfUndefOrPoison() (NFC)

Use contains() to check set membership, and adjust an oddly
structured loop.

[ValueTracking] Limit scan when checking poison UB (PR50155)

The current code can scan an unlimited number of instructions,
if the containing basic block is very large. The test case from
PR50155 contains a basic block with approximately 100k instructions.

To avoid this, limit the number of instructions we inspect. At
the same time, drop the limit on the number of basic blocks, as
this will be implicitly limited by the number of instructions as
well.

asan: fix a windows test

Before commit "sanitizer_common: introduce kInvalidTid/kMainTid"
asan invalid/unknown thread id was 0xffffff, so presumably we printed "T16777215".
Now it's -1, so we print T-1. Fix the test.
I think the new format is even better, "T-1" clearly looks like something special
rather than a random large number.

Reviewed By: vitalybuka

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

Add support for llvm.assume intrinsic to the LoadStoreVectorizer pass

Patch by Viacheslav Nikolaev. Thanks!

[tsan] Remove special SyncClock::kInvalidTid

Followup for D101428.

Reviewed By: dvyukov

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

[OpenMP] Fix second debug name from map clause

This patch fixes a bug from D89802.  For example, without it, Clang
generates x as the debug map name for both x and y in the following
example:

```
 #pragma omp target map(to: x, y)
 x = y = 1;
```

Reviewed By: jhuber6

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

[gn build] Port 2d28100bf2e4

[lld-macho] Parse & emit the N_ARM_THUMB_DEF symbol flag

Eventually we'll use this flag to properly handle bl/blx
opcodes.

Reviewed By: #lld-macho, gkm

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

[lld-macho] Initial scaffolding for ARM32 support

This just parses the `-arch armv7` and emits the right header flags.
The rest will be slowly fleshed out in upcoming diffs.

Reviewed By: #lld-macho, gkm

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

[libc++] Fix constexpr-ness of std::tuple's constructor

Mentioned in https://reviews.llvm.org/D96523.

[TTI] NFC: Change getTypeLegalizationCost to return InstructionCost.

This patch migrates the TTI cost interfaces to return an InstructionCost.

See this patch for the introduction of the type: https://reviews.llvm.org/D91174
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2020-November/146408.html

Reviewed By: sdesmalen, kparzysz

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

[InstCombine] Added tests for PR50172, NFC

[MachineFunction] Make comment for TracksLiveness more clearer

As discussed in https://lists.llvm.org/pipermail/llvm-dev/2021-April/150225.html,
the current comments for TracksLiveness property and isKill flag are confusing.
This patch makes the comments more clearer.

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

[llvm-reduce] Don't unset dso_local on implicitly dso_local GVs

This introduces a flag that aborts if we ever reduce to IR that fails
the verifier.

Reviewed By: swamulism, arichardson

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

[NFC][tsan] Fix cast after D101428

[llvm-reduce] Add flag to only run specific passes

Reviewed By: fhahn, hans

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

[libc++] [test] Recommit the unsetting of LC_COLLATE in the builder script.

This re-reverts one piece of 1b885573327d0f6b36f24ad23d243642f658750b,
reapplying one piece of D101437 (but not the "service"-queue piece of it).

It turns out that the behavior of `grep [^ -~]`, or even `grep [A-Z]`,
depends on locale, specifically `LC_COLLATE`. So we want to make sure
we're not in any weird locale, no matter what machine we're running on.
Yes, "en_US.UTF-8" counts as weird!
https://stackoverflow.com/questions/67320156/misbehavior-of-gnu-grep-when-grepping-for-ignores-spaces
https://stackoverflow.com/questions/6799872/how-to-make-grep-a-z-independent-of-locale

Revert "AMDGPU/llvm-readobj: Add missing tests for note parsing/displaying"

This reverts commit c9c4676a458b1ef99ffb67b43cfd87d6c27a448c.

Reason for revert: note-amd-valid-v3.s test fails if AMDGPU is not built.

[libcxx] Use joined format for include flag on Windows

Without this, CMake deduplicates the /I flag breaking the build. See
https://cmake.org/cmake/help/v3.13/command/target_compile_options.html
for more details on why this is needed.

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

[llvm-objdump] add -v alias for --version

Used by the Linux kernel's CONFIG_X86_DECODER_SELFTEST.

Link: https://github.com/ClangBuiltLinux/linux/issues/1130
Reviewed By: MaskRay, jhenderson, rupprecht

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

[M68k] fix -Wdefaulted-function-deleted and -Woverloaded-virtual

Fixes the following warnings observerd when building the experimental
m68k backend (-DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD="M68k"):

../lib/Target/M68k/M68kMachineFunction.h:71:3: warning: explicitly
defaulted default constructor is implicitly deleted
[-Wdefaulted-function-deleted]
  M68kMachineFunctionInfo() = default;
  ^
../lib/Target/M68k/M68kMachineFunction.h:24:20: note: default
constructor of 'M68kMachineFunctionInfo' is implicitly deleted because
field 'MF' of reference type 'llvm::MachineFunction &' would not be
initialized
  MachineFunction &MF;
                   ^
In file included from ../lib/Target/M68k/M68kISelLowering.cpp:18:
In file included from ../lib/Target/M68k/M68kSubtarget.h:17:
../lib/Target/M68k/M68kFrameLowering.h:60:8: warning:
'llvm::M68kFrameLowering::emitCalleeSavedFrameMoves' hides overloaded
virtual functions [-Woverloaded-virtual]
  void emitCalleeSavedFrameMoves(MachineBasicBlock &MBB,
       ^
../include/llvm/CodeGen/TargetFrameLowering.h:215:3: note: hidden
overloaded virtual function
'llvm::TargetFrameLowering::emitCalleeSavedFrameMoves' declared here:
different number of parameters (2 vs 3)
  emitCalleeSavedFrameMoves(MachineBasicBlock &MBB,
  ^
../include/llvm/CodeGen/TargetFrameLowering.h:218:16: note: hidden
overloaded virtual function
'llvm::TargetFrameLowering::emitCalleeSavedFrameMoves' declared here:
different number of parameters (4 vs 3)
  virtual void emitCalleeSavedFrameMoves(MachineBasicBlock &MBB,
               ^

pr/50071

Reviewed By: myhsu

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

[ADT] Add llvm::remove_cvref and llvm::remove_cvref_t

Reviewed By: dblaikie

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

[libc++] Revert the change that runs clang-format and generated-output in the service queue

This reverts commit 6712534ebc6f84f0b178a19bf17b7b2bd852f6eb.

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

Support: Stop using F_{None,Text,Append} compatibility synonyms, NFC

Stop using the compatibility spellings of `OF_{None,Text,Append}`
left behind by 1f67a3cba9b09636c56e2109d8a35ae96dc15782. A follow-up
will remove them.

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

Add patterns to lower vector.multi_reduction into a sequence of vector.reduction

Three patterns are added to convert into vector.multi_reduction into a
sequence of vector.reduction as the following:

- Transpose the inputs so inner most dimensions are always reduction.
- Reduce rank of vector.multi_reduction into 2d with inner most
reduction dim (get the 2d canical form)
- 2D canonical form is converted into a sequence of vector.reduction.

There are two things we might worth in a follow up diff:

- An scf.for (maybe optionally) around vector.reduction instead of unrolling it.
- Breakdown the vector.reduction into a sequence of vector.reduction
(e.g tree-based reduction) instead of relying on how downstream dialects
handle it.
  Note: this will requires passing target-vector-length

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

[AArch64] Fix lowering for fshl/fshr with SVE types.

These operations don't exist natively, so just let the
target-independent code expand to plain shifts.

The generated sequences could probably be optimized a bit more, but
they seem good enough for now.

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

[OpenMP][CMake] Use in-project clang as CUDA->IR compiler.

If available, use the clang that is already built in the same project as
CUDA compiler unless another executable is explicitly defined. This also
ensures the generated deviceRTL IR will be consistent with the version
of Clang.

This patch is required to reliably test OpenMP offloading in a buildbot
without either a two-stage build (e.g. with LLVM_ENABLE_RUNTIMES) or a
separately installed clang on the worker that will eventually become
outdated.

Reviewed By: tianshilei1992

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

[gn build] Port c6f20d70a8c9

[ADT] Add STLForwardCompat.h and llvm::disjunction

Move some types in STLExtras.h which are named and behave identically to
STL types from future standards into a dedicated header. This keeps them
organized (they are not "extras" in the same sense as most types in
STLExtras.h are) and fixes circular dependencies in future patches.

Reviewed By: dblaikie

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

[NFC] Refactor ExecuteAssembler in cc1as_main.cpp

Introduce an extra scope (another static function) to replace calls to
`unique_ptr::reset` with implicit destructors via RAII.

Reviewed By: MaskRay

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

[gn build] Port 7c17731596e9

[gn build] Port 5a3309f82576

[libcxx][ranges] adds `ranges::range`, `ranges::common_range`, and range aliases

* `std::ranges::range`
* `std::ranges::sentinel_t`
* `std::ranges::range_difference_t`
* `std::ranges::range_value_t`
* `std::ranges::range_reference_t`
* `std::ranges::range_rvalue_reference_t`
* `std::ranges::common_range`

`range_size_t` depends on `sized_range` and will be added alongside it.

Implements parts of:
    * P0896R4 The One Ranges Proposal`

Depends on D100255.

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

[libcxx][ranges] adds `range` access CPOs

* `std::ranges::begin`
* `std::ranges::cbegin`
* `std::ranges::end`
* `std::ranges::cend`
* `std::ranges::iterator` (required for `end`)

Implements parts of:
    * P0896R4 The One Ranges Proposal`

Co-author: @zoecarver

Depends on D90999, D100160.

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

[SLP]Fix the crash on cost calculation if non-compatible vectors shuffled.

If the extracts from the non-power-2 vectors are recognized as shuffles,
need some extra checks to not crash cost calculations if trying to gext
the ecost for subvector extracts. In this case need to check carefully
that we do not exit out of bounds of the original vector, otherwise the
TTI's cost model will crash on assert.

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

[AArch64] Adds a pre-indexed paired Load/Store optimization for LDR-STR.

This patch merges STR<S,D,Q,W,X>pre-STR<S,D,Q,W,X>ui and
LDR<S,D,Q,W,X>pre-LDR<S,D,Q,W,X>ui instruction pairs into a single
STP<S,D,Q,W,X>pre and LDP<S,D,Q,W,X>pre instruction, respectively.
For each pair, there is a MIR test that verifies this optimization.

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

Change-Id: Ie97a20c8c716c08492fe229c22e14e3c98ef08b7

[clang] Update comments on another libstdc++ HACK

Document relevant gcc versions and dates.

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

[flang] Allow KIND type parameters to be used as LEN parameters of components

When producing the runtime type information for a component of a derived type
that had a LEN type parameter, we were not allowing a KIND parameter of the
derived type.  This was causing one of the NAG correctness tests to fail
(.../hibiya/d5.f90).

I added a test to our own test suite to check for this.

Also, I fixed a typo in .../module/__fortran_type_info.f90.

I allowed KIND type parameters to be used for the declarations of components
that use LEN parameters by constant folding the value of the LEN parameter.  To
make the constant folding work, I had to put the semantics::DerivedTypeSpec of
the associated derived type into the folding context.  To get this
semantics::DerivedTypeSpec, I changed the value of the semantics::Scope object
that was passed to DescribeComponent() to be the derived type scope rather than
the containing non-derived type scope.

This scope change, in turn, caused differences in the symbol table output that
is checked in typeinfo01.f90.  Most of these differences were in the order that
the symbols appeared in the dump.  But one of them changed one of the values
from "CHARACTER(2_8,1)" to "CHARACTER(1_8,1)".  I'm not sure if these changes
are significant.  Please verify that the results of this test are still valid.

Also, I wonder if there are other situations in this code where we should be
folding constants.  For example, what if the field of a component has a
component whose type is a PDT with a LEN type parameter, and the component's
declaration depends on the KIND type parameter of the current PDT.  Here's an
example:

  type string(stringkind)
    integer,kind :: stringkind
    character(stringkind) :: value
  end type string

  type outer(kindparam)
    integer,kind :: kindparam
    type(string(kindparam)) :: field
  end type outer

I don't understand the code or what it's trying to accomplish well enough to
figure out if such cases are correctly handled by my new code.

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

[analyzer] Fix assertion in SVals.h

Fix assertion in SVals.h apparently caused by
https://reviews.llvm.org/D89055.

clang:clang/include/clang/StaticAnalyzer/Core/PathSensitive/SVals.h:596:
clang::ento::loc::MemRegionVal::MemRegionVal(const clang::ento::MemRegion *):
  Assertion `r' failed.

Backtrace:
...
     clang/include/clang/StaticAnalyzer/Core/PathSensitive/SVals.h:597:3
     clang::QualType, clang::QualType)
     clang/lib/StaticAnalyzer/Core/SValBuilder.cpp:773:18
     clang::QualType, clang::QualType)
     clang/lib/StaticAnalyzer/Core/SValBuilder.cpp:612:12
     clang::QualType) clang/lib/StaticAnalyzer/Core/SValBuilder.cpp:587:12
     namespace)::RegionBindingsRef const&, clang::ento::Loc, clang::QualType)
     clang/lib/StaticAnalyzer/Core/RegionStore.cpp:1510:24
...

Reviewed By: ASDenysPetrov

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

[AArch64][SVE] Remove unused function missed from D101302

The functionality in SVEIntrinsicOpts::isReinterpretToSVBool was moved in
D101302, however the original now unused function was not removed (NFC).

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

[lldb] Change DumpDataExtractorTest function names to lldb style (NFC)

Revert "[CodeGen][ARM] Implement atomicrmw as pseudo operations at -O0"

This reverts commit 3338290c187b254ad071f4b9cbf2ddb2623cefc0.

Broke expensive checks on debian.

[lldb] DumpDataExtractor tests for item byte size errors

Reviewed By: teemperor

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

[CodeGen][ARM] Implement atomicrmw as pseudo operations at -O0

atomicrmw instructions are expanded by AtomicExpandPass before register allocation
into cmpxchg loops. Register allocation can insert spills between the exclusive loads
and stores, which invalidates the exclusive monitor and can lead to infinite loops.

To avoid this, reimplement atomicrmw operations as pseudo-instructions and expand them
after register allocation.

Floating point legalisation:
f16 ATOMIC_LOAD_FADD(*f16, f16) is legalised to
f32 ATOMIC_LOAD_FADD(*i16, f32) and then eventually
f32 ATOMIC_LOAD_FADD_16(*i16, f32)

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

[TableGen] Fix two bugs in 'defm' when complex 'assert' is involved.

This patch fixes two bugs that arise when a 'defm' inherits from a multiclass
and also from a class with assertions.

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

AMDGPU/llvm-readobj: Add missing tests for note parsing/displaying

This is a follow up review/change for https://reviews.llvm.org/D95638

Add valid note tests for code object v2 notes:
  - NT_AMD_HSA_CODE_OBJECT_VERSION (required yaml2obj update)
  - NT_AMD_HSA_HSAIL (required yaml2obj update)
  - NT_AMD_HSA_ISA_VERSION (required yaml2obj update)
  - NT_AMD_HSA_METADATA
  - NT_AMD_HSA_ISA_NAME
  - NT_AMD_PAL_METADATA

Add valid note tests for code object v3 notes:
  - NT_AMDGPU_METADATA

Add invalid note tests for code object v2 notes:
  - NT_AMD_HSA_CODE_OBJECT_VERSION (required yaml2obj update)
  - NT_AMD_HSA_HSAIL (required yaml2obj update)
  - NT_AMD_HSA_ISA_VERSION (required yaml2obj update)

Add invalid note tests for code object v3 notes:
  - NT_AMDGPU_METADATA

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

[lldb] More tests for DumpDataExtractor

* Using a base address or skipping it with LLDB_INVALID_ADDRESS
* Using a data offset, which does not effect the printed addresses
* Not providing an output stream
* Formatting a double sized HexFloat
* Formatting over multiple lines

Since address printing now has its own test,
I've removed the base address from all the format
type tests.

The multi line tests still use a base address to check that
it's incremented correctly for each new line.

Reviewed By: teemperor

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

[SimpleLoopUnswitch] Port partially invariant unswitch from LoopUnswitch to SimpleLoopUnswitch

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

[PowerPC] Add new infrastructure to select load/store instructions, update P8/P9 load/store patterns.

This patch introduces a new infrastructure that is used to select the load and
store instructions in the PPC backend.

The primary motivation is that the current implementation of selecting load/stores
is dependent on the ordering of patterns in TableGen. Given this limitation, we
are not able to easily and reliably generate the P10 prefixed load and stores
instructions (such as when the immediates that fit within 34-bits). This
refactoring is meant to provide us with more control over the patterns/different
forms to exploit, as well as eliminating dependency of pattern declaration in TableGen.

The idea of this refactoring is that it introduces a set of addressing modes that
correspond to different instruction formats of a particular load and store
instruction, along with a set of common flags that describes a load/store.
Whenever a load/store instruction is being selected, we analyze the instruction
and compute a set of flags for it. The computed flags are then used to
select the most optimal load/store addressing mode.

This patch is the first of a series of patches to be committed - it contains the
initial implementation of the refactored load/store selection infrastructure and
also updates P8/P9 patterns to adopt this infrastructure. The idea is that
incremental patches will add more implementation and support, and eventually
the old implementation will be removed.

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

[XCOFF][AIX] Add Global Variables Directly to TOC for 32 bit AIX

Summary:
This patch implements the backend implementation of adding global variables
directly to the table of contents (TOC), rather than adding the address of the
variable to the TOC.
Currently, this patch will look for the "toc-data" attribute on symbols in the
IR, and then add those symbols to the TOC.
ATM, this is implemented for 32 bit AIX.

Reviewers: sfertile
Differential Revision: https://reviews.llvm.org/D101178

[clang] Fix assert() crash when checking undeduced arg alignment

There already was a check for undeduced and incomplete types, but it
failed to trigger when outer type (SubstTemplateTypeParm in test) looked
fine, but inner type was not.

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

[AMDGPU] Add test for set_gpr_idx removal with conditional branches

sanitizer_common: introduce kInvalidTid/kMainTid

Currently we have a bit of a mess related to tids:
 - sanitizers re-declare kInvalidTid multiple times
 - some call it kUnknownTid
 - implicit assumptions that main tid is 0
 - asan/memprof claim their tids need to fit into 24 bits,
   but this does not seem to be true anymore
 - inconsistent use of u32/int to store tids

Introduce kInvalidTid/kMainTid in sanitizer_common
and use them consistently.

Reviewed By: vitalybuka

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

[gn build] Port 43bc584dc05e

[VE] VP intrinsics are legal

[VP,Integer,#2] ExpandVectorPredication pass

This patch implements expansion of llvm.vp.* intrinsics
(https://llvm.org/docs/LangRef.html#vector-predication-intrinsics).

VP expansion is required for targets that do not implement VP code
generation. Since expansion is controllable with TTI, targets can switch
on the VP intrinsics they do support in their backend offering a smooth
transition strategy for VP code generation (VE, RISC-V V, ARM SVE,
AVX512, ..).

Reviewed By: rogfer01

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

[AMDGPU] Add implicit negative check for the set_gpr_idx tests

The only effect of the optimization is to remove s_set_gpr_idx_*
instructions, and update_mir_test_checks.py always inserts CHECK: rather
than CHECK-NEXT: checks, so without this implicit negative check, the
tests would always pass even if the optimization did nothing.

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

[OpenCL] Prevent adding vendor extensions for all targets

Removed extension begin/end pragma as it has no effect and
it is added unconditionally for all targets.

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

[lld/mac] Remove unused -L%t flags from tests

No behavior change.

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

[docs]Added llvm/bindings section

Added information about language bindings provided by LLVM.

Reviewed By: xgupta, gandhi21299

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

[lld/mac] Tweak two comments and fix style on one variable name

Cosmetic, no behavior change.

[MCA] Fix CarryOver check in the DispatchStage (PR50174).

Early exit from method DispatchStage::isAvailable() if the dispatch group is
already full. Not all instructions declare at least one uOP.
Fixes PR50174.

[clang] Refactor mustprogress handling, add it to all loops in c++11+.

Currently Clang does not add mustprogress to inifinite loops with a
known constant condition, matching C11 behavior. The forward progress
guarantee in C++11 and later should allow us to add mustprogress to any
loop (http://eel.is/c++draft/intro.progress#1).

This allows us to simplify the code dealing with adding mustprogress a
bit.

Reviewed By: aaron.ballman, lebedev.ri

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

[AMDGPU] Fix inconsistent ---/... in MIR tests and regenerate checks

In some cases the lack of --- or ... confused update_mir_test_checks.py
into not adding any checks for a function.

[libc++] [test] Run the clang-format and generated-output checks on the "service" queue

As these jobs only run in a couple seconds, and block starting of
other jobs, they can run on the "service" queue which doesn't get
blocked by other long-running jobs.

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

[libc++] Minor cleanups in <iterator>. NFCI.

[ARM][MVE] vcreateq lane ordering for big endian

Use of bitcast resulted in lanes being swapped for vcreateq with big
endian. Fix this by using vreinterpret. No code change for little
endian. Adds IR lit test.

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

[clangd][NFC] Remove unnecessary string captures in lambdas.

Due to a somewhat annoying, but necessary, shortfall in -Wunused-lambda-capture, These unused captures aren't warned about.

Reviewed By: kadircet

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

Require shell for lld/test/MachO/reproduce.s

as a way of not running it on Windows, where the file paths when
extracting repro2.tar can become longer than the maximum file length
limit (depending on the build dir name) and cause the test to fail.

(See https://crbug.com/1204463 for example test failure.)

clang-format: [JS] handle "off" in imports

Previously, the JavaScript import sorter would ignore `// clang-format
off` and `on` comments. This change fixes that. It tracks whether
formatting is enabled for a stretch of imports, and then only sorts and
merges the imports where formatting is enabled, in individual chunks.

This means that there's no meaningful total order when module references are mixed
with blocks that have formatting disabled. The alternative approach
would have been to sort all imports that have formatting enabled in one
group. However that raises the question where to insert the
formatting-off block, which can also impact symbol visibility (in
particular for exports). In practice, sorting in chunks probably isn't a
big problem.

This change also simplifies the general algorithm: instead of tracking
indices separately and sorting them, it just sorts the vector of module
references. And instead of attempting to do fine grained tracking of
whether the code changed order, it just prints out the module references
text, and compares that to the previous text. Given that source files
typically have dozens, but not even hundreds of imports, the performance
impact seems negligible.

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

[NARY] Don't optimize min/max if there are side uses (part2)

Previous attempt to fix infinite recursion in min/max reassociation was not fully successful (D100170). Newly discovered failing case is due to not properly handled when there is a single use. It should be processed separately from 2 uses case.

Reviewed By: mkazantsev

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

[Doc] Fix sphinx warnings about wrong code-block format

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

[Passes] Run sinking/hoisting in SimplifyCFG earlier.

Hoisting and sinking instructions out of conditional blocks enables
additional vectorization by:

1. Executing memory accesses unconditionally.
2. Reducing the number of instructions that need predication.

After disabling early hoisting / sinking, we miss out on a few
vectorization opportunities. One of those is causing a ~10% performance
regression in one of the Geekbench benchmarks on AArch64.

This patch tires to recover the regression by running hoisting/sinking
as part of a SimplifyCFG run after LoopRotate and before LoopVectorize.

Note that in the legacy pass-manager, we run LoopRotate just before
vectorization again and there's no SimplifyCFG run in between, so the
sinking/hoisting may impact the later run on LoopRotate. But the impact
should be limited and the benefit of hosting/sinking at this stage
should outweigh the risk of not rotating.

Compile-time impact looks slightly positive for most cases.
http://llvm-compile-time-tracker.com/compare.php?from=2ea7fb7b1c045a7d60fcccf3df3ebb26aa3699e5&to=e58b4a763c691da651f25996aad619cb3d946faf&stat=instructions

NewPM-O3: geomean -0.19%
NewPM-ReleaseThinLTO: geoman -0.54%
NewPM-ReleaseLTO-g: geomean -0.03%

With a few benchmarks seeing a notable increase, but also some
improvements.

Alternative to D101290.

Reviewed By: lebedev.ri

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

[AArch64][SVE] Lower index_vector to step_vector

As discussed in D100107, this patch first convert index_vector to
step_vector, and convert step_vector back to index_vector after LegalizeDAG.

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

[InlineCost] CallAnalyzer: use TTI info for extractvalue - they are free (PR50099)

It seems incorrect to use TTI data in some places,
and override it in others. In this case, TTI says
that `extractvalue` are free, yet we bill them.

While this doesn't address https://bugs.llvm.org/show_bug.cgi?id=50099 yet,
it reduces the cost from 55 to 50 while the threshold is 45.

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

Wrap edit line configuration calls into helper functions

Currently we call el_set directly to configure the editor in the libedit
wrapper.  There are some cases in which this causes extra casting, but we pass
captureless lambdas as function pointers, which should work out of the box.
Since el_set takes varargs, if the cast is incorrect or if the cast is not
present, it causes a run time failure rather than compile error.  This change
makes it so a few different types of configuration is done inside a helper
function to provide type safety and eliminate that casting.  I didn't do all
edit line configuration because I'm not sure how important it was in other cases
and it might require something more general keep up with libedit's signature.
I'm open to suggestions, though.

Reviewed By: teemperor, JDevlieghere

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

[AMDGPU] Tidy up some simple expressions for clarity NFC

Slight refactor for clarity.

Change-Id: Ib25e7f4582c67a7c57f066cfd5382c1405d7d4c5

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

[JITLink] Minor fix to avoid Windows compiler warning for static-cast

Change-Id: Id0c1d5535b53e2aebe314151c0efa585e763f3f6

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

[AArch64] Change __ARM_FEATURE_FP16FML macro name to  __ARM_FEATURE_FP16_FML

The "Arm C Language extensions" document (the current version can be
found at https://developer.arm.com/documentation/101028/0012/?lang=en)
states that the name of the feature test macro for the FP16 FML extension
is __ARM_FEATURE_FP16_FML.

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

[lldb] Add tests for DumpDataExtractor formats

Covering basic cases where you have 1 item on 1 line.

Apart from eFormatCharArray, where using multiple lines
highlights the difference between it and eFormatVectorOfChar.

Reviewed By: #lldb, teemperor

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

[RISCV][NFC] Merge RV32/RV64 test checks with a common prefix

[RISCV] Support STEP_VECTOR with a step greater than one

DAGCombiner was recently taught how to combine STEP_VECTOR nodes,
meaning the step value is no longer guaranteed to be one by the time it
reaches the backend for lowering.

This patch supports such cases on RISC-V by lowering to other step
values to a multiply following the vid.v instruction. It includes a
small optimization for common cases where the multiply can be expressed
as a shift left.

Reviewed By: rogfer01

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

[llvm][Support][NFC] Fix fallthrough attribute indentation

The attribute does not belong to the if statement before and trips up
gcc's indentation checker.

tsan: fix fork syscall test

Arm64 builders failed with:
error: use of undeclared identifier 'SYS_fork'
https://lab.llvm.org/buildbot/#/builders/7/builds/2575

Indeed, not all arches have fork syscall.
Implement fork via clone on these arches.

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

[GISel] Teach TableGen to check predicates of immediate operands in patterns

Reviewed By: dsanders

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

[AMDGPU] Simplify getWaitStatesSince. NFC.

[cmake] Use -ffunction-sections and -Wl,--gc-sections on MinGW targets

If compiling with GCC or linking with ld.bfd, these options have little
effect, but if built with Clang and linked with LLD, they provide a
quite notable size decrease - this shrinks an entire llvm-mingw
distribution package by 22%.

If building with BUILD_SHARED_LIBS or LLVM_BUILD_LLVM_DYLIB with LLD,
this requires a version of LLD that contains a fix for auto exporting
symbols from comdats, 2b01a417d7ccb001ccc1185ef5fdc967c9fac8d7.

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

Fix -fdebug-pass-structure test case

Pass structure can change when -O0 is given and extensions are used.

Reapply [llvm-readobj] [ARMWinEH] Fix handling of relocations and symbol offsets

When looking up data referenced from pdata/xdata structures, the
referenced data can be found in two different ways:
- For an unrelocated object file, it's located via a relocation
- For a relocated, linked image, the data is referenced with an
  (image relative) absolute address

For the latter case, the absolute address can optionally be
described with a symbol.

For the case of an object file, there's two offsets involved; one
immediate offset encoded in the data location that is modified by
the relocation, and a section offset in the symbol.

Previously, for the ExceptionRecord field, we printed the offset
from the symbol (only) but used the immediate offset ignoring
the symbol's address (using only the symbol's section) for printing
the exception data.

Add a helper method for doing the lookup and address calculation,
for simplifying the calling code and making all the cases consistent.

This addresses an existing FIXME comment, fixing printing of the
exception data for cases where relocations point at individual
symbols in the xdata section (which is what MSVC generates) instead of
all relocations pointing at the start of the xdata section (which is
what LLVM generates).

This also fixes printing of the function name for packed entries in
linked images.

Relanded with a format string fix in the formatSymbol function; one
can't use %X as format string for an uint64_t. That bug has been
present since this code was added in e6971cab306cd.

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

tsan: refactor fork handling

Commit efd254b6362 ("tsan: fix deadlock in pthread_atfork callbacks")
fixed another deadlock related to atfork handling.
But builders with DCHECKs enabled reported failures of
pthread_atfork_deadlock2.c and pthread_atfork_deadlock3.c tests
related to the fact that we hold runtime locks on interceptor exit:
https://lab.llvm.org/buildbot/#/builders/70/builds/6727
This issue is somewhat inherent to the current approach,
we indeed execute user code (atfork callbacks) with runtime lock held.

Refactor fork handling to not run user code (atfork callbacks)
with runtime locks held. This change does this by installing
own atfork callbacks during runtime initialization.
Atfork callbacks run in LIFO order, so the expectation is that
our callbacks run last, right before the actual fork.
This way we lock runtime mutexes around fork, but not around
user callbacks.

Extend tests to also install after fork callbacks just to cover
more scenarios. Some tests also started reporting real races
that we previously suppressed.

Also extend tests to cover fork syscall support.

Reviewed By: vitalybuka

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

[debugserver] Use add_lldb_library instead of add_library

Use add_lldb_library to ensure debugserver inherits the defines set by
llvm and lldb.

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

[msan] Add static to some msan allocator functions

This is to help review refactor the allocator code.
So it is easy to see which are the real public interfaces.

Reviewed By: vitalybuka

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

Pre-commit test for PPC vector extraction test

[InlineCost] Remove visitUnaryInstruction()

The simplifyInstruction() in visitUnaryInstruction() does not trigger
for all of check-llvm. Looking at all delegates to UnaryInstruction in
InstVisitor, the only instructions that either don't have a visitor in
CallAnalyzer, or redirect to UnaryInstruction, are VAArgInst and Alloca.
VAArgInst will never get simplified, and visitUnaryInstruction(Alloca)
would always return false anyway.

Reviewed By: mtrofin, lebedev.ri

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

[AMDGPU] Skip promote-alloca for insertelement/insertvalue users

It is difficult to track the users of vector and aggregate types.

Reviewed by: arsenm

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

[RISCV] Fix StackOffset calculation when using sp to access the fixed stack object in the case of rvv vector objects existed

When rvv vector objects existed, using sp to access the fixed stack object will pass the rvv vector objects field. So the StackOffset needs add a scalable offset of the size of rvv vector objects field

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

[RISCV] Precommit a test case that test accessing a fixed object when has rvv vector object existed

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

[CMake][compiler-rt] avoid conflict with builtin check_linker_flag

Rename `check_linker_flag` in compiler_rt to avoid conflict. Follow up
as the fix in D100901.

Patched by radford.

Reviewed By: MaskRay

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

[MS] Preserve base register %rbx around cpuid

This patch copies implementation from cpuid.h, which preserve base register %rbx around cpuid. It fixes PR50133.

Reviewed By: rnk

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

[AArch64][GlobalISel] Fix width value for G_SBFX/G_UBFX

When creating G_SBFX/G_UBFX opcodes, the last operand is the
width instead of the bit position. The bit position is used
for the AArch64 SBFM and UBFM instructions. The bit position
is converted to a width if the SBFX/UBFX aliases are generated.
For other SBMF/UBFM aliases, such as shifts, the bit position
is used.

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