[Analysis][LoopVectorize] rename "Unsafe" variables/methods; NFC

Similar to b3a33553aec7, but this shows a TODO and a potential
miscompile is already present.

We are tracking an FP instruction that does *not* have FMF (reassoc)
properties, so calling that "Unsafe" seems opposite of the common
reading.

I also removed one getter method by rolling the null check into
the access. Further simplification may be possible.

The motivation is to clean up the interactions between FMF and
function-level attributes in these classes and their callers.

The new test shows that there is an existing bug somewhere in
the callers. We assumed that the original code was fully 'fast'
and so we produced IR with 'fast' even though it was just 'reassoc'.

[OPENMP]Fix PR48759:  "fatal error" when compile with preprocessed file.

If the file in line directive does not exist on the system we need, to
use the original file to get its file id.

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

[SystemZ][z/OS] Missing non-posix functions libc++

The aim is to add missing non-posix functions for z/OS libc++ (strtod_l and strtof_l).

Reviewed By: #libc, ldionne

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

Revert "AMDGPU/GlobalISel: Combine zext(trunc x) to x after RegBankSelect"

This reverts commit bf5a5826504754788a8f1e3fec7a7dc95cda5782.
Also depends on now-reverted 4c8fb7ddd6fa49258e0e9427e7345fb56ba522d4

Revert "[GlobalISel] Combine zext(trunc x) to x"

This reverts commit 4112299ee761a9b6a309c8ff4a7e75f8c8d8851b.
Seems to depend on 4c8fb7ddd6fa49258e0e9427e7345fb56ba522d4 which
is being reverted.

Revert "[GlobalISel] Start using vectors in GISelKnownBits"

This reverts commit 4c8fb7ddd6fa49258e0e9427e7345fb56ba522d4.
Breaks check-llvm everywhere, see https://reviews.llvm.org/D96122

[mlir][linalg] Add suffix "Op" to pooling TC ops.

Reviewed By: antiagainst

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

[pstl] A hot fix for

Commit 5856f202
by Mikhail Dvorskiy, 02/13/2021 08:28 PM
parent f515ca89

Iterator types renaming: ForwardIterator -> RandomAccessIterator; for parallel patterns/bricks

https://reviews.llvm.org/D96266

[mlir][Vector] Add folding of vector transfers from/into tensor producing ops.

Add a folder to rewrite a sequence such as:

```
   %t1 = ...
   %v = vector.transfer_read %t0[%c0...], {masked = [false...]} :
     tensor<static_sizesxf32>, vector<static_sizesxf32>
  %t2 = vector.transfer_write %v, %t1[%c0...] {masked = [false...]} :
     vector<static_sizesxf32>, tensor<static_sizesxf32>
```

into:

```
   %t0
```

The producer of t1 may or may not be DCE'd depending on whether it is a
block argument or has side effects.

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

[AST][PCH][ASTImporter] Fix UB caused by uninited SwitchStmt member

The SwitchStmt::FirstCase member is not initialized when the AST is
built by the ASTStmtReader. See the below code of
ASTStmtReader::VisitSwitchStmt in the case where the for loop does not
have any iterations:
```
    // ... more code ...
    SwitchCase *PrevSC = nullptr;
    for (auto E = Record.size(); Record.getIdx() != E; ) {
      SwitchCase *SC = Record.getSwitchCaseWithID(Record.readInt());
      if (PrevSC)
        PrevSC->setNextSwitchCase(SC);
      else
        S->setSwitchCaseList(SC); // Sets FirstCase !!!

      PrevSC = SC;
    }
  } // return
```
Later, in ASTNodeImporter::VisitSwitchStmt,
we have a condition that depends on this uninited value:
```
  for (SwitchCase *SC = S->getSwitchCaseList(); SC != nullptr;
       SC = SC->getNextSwitchCase()) {
       // ... more code ...
  }

```
This is clearly an UB. This causes non-deterministic crashes when
ClangSA analyzes some code with CTU. See the below report by valgrind
(the whole valgrind output is attached):
```
==31019== Conditional jump or move depends on uninitialised value(s)
==31019==    at 0x12ED1983: clang::ASTNodeImporter::VisitSwitchStmt(clang::SwitchStmt*) (ASTImporter.cpp:6195)
==31019==    by 0x12F1D509: clang::StmtVisitorBase<std::add_pointer, clang::ASTNodeImporter, llvm::Expected<clang::Stmt*>>::Visit(clang::Stmt*) (StmtNodes.inc:591)
==31019==    by 0x12EE4FDF: clang::ASTImporter::Import(clang::Stmt*) (ASTImporter.cpp:8484)
==31019==    by 0x12F09498: llvm::Expected<clang::Stmt*> clang::ASTNodeImporter::import<clang::Stmt>(clang::Stmt*) (ASTImporter.cpp:164)
==31019==    by 0x12F3A1F5: llvm::Error clang::ASTNodeImporter::ImportArrayChecked<clang::Stmt**, clang::Stmt**>(clang::Stmt**, clang::Stmt**, clang::Stmt**) (ASTImporter.cpp:653)
==31019==    by 0x12F13152: llvm::Error clang::ASTNodeImporter::ImportContainerChecked<llvm::iterator_range<clang::Stmt**>, llvm::SmallVector<clang::Stmt*, 8u> >(llvm::iterator_range<clang::Stmt**> const&, llvm::SmallVector<clang::Stmt*, 8u>&) (ASTImporter.cpp:669)
==31019==    by 0x12ED099F: clang::ASTNodeImporter::VisitCompoundStmt(clang::CompoundStmt*) (ASTImporter.cpp:6077)
==31019==    by 0x12F1CC2D: clang::StmtVisitorBase<std::add_pointer, clang::ASTNodeImporter, llvm::Expected<clang::Stmt*>>::Visit(clang::Stmt*) (StmtNodes.inc:73)
==31019==    by 0x12EE4FDF: clang::ASTImporter::Import(clang::Stmt*) (ASTImporter.cpp:8484)
==31019==    by 0x12F09498: llvm::Expected<clang::Stmt*> clang::ASTNodeImporter::import<clang::Stmt>(clang::Stmt*) (ASTImporter.cpp:164)
==31019==    by 0x12F13275: clang::Stmt* clang::ASTNodeImporter::importChecked<clang::Stmt*>(llvm::Error&, clang::Stmt* const&) (ASTImporter.cpp:197)
==31019==    by 0x12ED0CE6: clang::ASTNodeImporter::VisitCaseStmt(clang::CaseStmt*) (ASTImporter.cpp:6098)
```

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

AMDGPU/GlobalISel: Combine zext(trunc x) to x after RegBankSelect

RegBankSelect creates zext and trunc when it selects banks for uniform i1.
Add zext_trunc_fold from generic combiner to post RegBankSelect combiner.

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

[GlobalISel] Combine zext(trunc x) to x

Combine zext(trunc x) to x when truncated bits are known to be zero.

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

[GlobalISel] Start using vectors in GISelKnownBits

For vectors we consider a bit as known if it is the same for all demanded
vector elements (all elements by default). KnownBits BitWidth for vector
type is size of vector element. Add support for G_BUILD_VECTOR.
This allows combines of urem_pow2_to_mask in pre-legalizer combiner.

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

Revert "[Coverage] Emit gap region between statements if first statements contains terminate statements."

This reverts commit 2d7374a0c680f96bdcdb3d05034a93bf145d140f.
Breaks ContinuousSyncMode/basic.c in check-profile on macOS.

[Analysis][LoopVectorize] rename "Unsafe" variables/methods; NFC

We are tracking an FP instruction that does *not* have FMF (reassoc)
properties, so calling that "Unsafe" seems opposite of the common
reading.

I also removed one getter method by rolling the null check into
the access. Further simplification seems possible.

The motivation is to clean up the interactions between FMF and
function-level attributes in these classes and their callers.

[CodeGenPrepare] Eliminate llvm.expect before removing empty blocks

CodeGenPrepare currently first removes empty blocks, then in a loop
performs other optimizations. One of those optimizations is the removal
of call instructions that invoke @llvm.assume, which can create new
empty blocks.

This means that when a branch only contains a call to __builtin_assume(),
the empty branch will survive into MIR, and will then only be
half-removed by MIR-level optimizations (e.g. removing the branch but
leaving the condition intact).

Fix it by eliminating @llvm.expect builtin calls before removing empty
blocks.

Reviewed By: bkramer

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

[lldb] Apply gdb-remote timeout to platform connections as well

We have a plugin.process.gdb-remote.packet-timeout setting, which can be
used to control how long the lldb client is willing to wait before
declaring the server side dead. Our test suite makes use of this
feature, and sets the setting value fairly high, as the low default
value can cause flaky tests, particularly on slower bots.

After fixing TestPlatformConnect (one of the few tests exercising the
remote platform capabilities of lldb) in 4b284b9ca, it immediately
started being flaky on the arm bots. It turns out this is because the
packet-timeout setting is not being applied to platform connections.

This patch makes the platform connections also respect the value of this
setting. It also adds a test which checks that the timeout value is
being honored.

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

[mlir][Linalg] Add folding of linalg.copy that are in fact identities.

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

[flang][driver] Add options for -fdefault* and -flarge-sizes

Add support for the following Fortran dialect options:
  - -default*
  - -flarge-sizes

It also adds two test cases:
  # For checking whether `flang-new` is passing options correctly to `flang-new -fc1`.
  # For checking if `fdefault-` arguments are processed properly.

Also moves the Dialect related option parsing to a dedicated function
and adds a member `defaultKinds()` to `CompilerInvocation`

Depends on: D96032

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

[AVR] Fix lifeness issues in the AVR backend

This patch is a large number of small changes that should hopefully not
affect the generated machine code but are still important to get right
so that the machine verifier won't complain about them.

The llvm/test/CodeGen/AVR/pseudo/*.mir changes are also necessary
because without the liveins the used registers are considered undefined
by the machine verifier and it will complain about them.

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

Add __builtin_isnan(__fp16) testcase

Reviewed By: rjmccall

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

[mlir] NFC - Add runner util functions to only print MemRef metadata.

These are useful to debug execution, without having to print the whole
content of a memref.

[mlir][Linalg] NFC - Add isOutputTensor to LinalgInterfaces.td

[clang-tidy][NFC] Update docs for bugprone-use-after-move

- Create a separate section on silencing erroneous warnings and add more material to it
- Add note that the check is flow-sensitive but not path-sensitive

Revert "Add __builtin_isnan(__fp16) testcase"

This reverts commit e77b5c40d57633a66842e75410585696895ecf4d because it
fails without 1b6eb56aa0ea2931866455a21a138fc09c08e905.

[DAG] TargetLowering::BuildUDIV - use APInt as const ref. NFCI.

Fixes clang-tidy warning.

[X86] X86TargetLowering::isSafeMemOpType - break if-else chain. NFCI.

All if-else blocks return - fixes clang-tidy warning.

[mlir] Initialize CUDA context lazily.

So we can remove the ignore-warning pragma again.

Reviewed By: herhut

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

Revert "Stop traping on sNaN in __builtin_isinf"

This reverts commit 1b6eb56aa0ea2931866455a21a138fc09c08e905 because the
invert logic for isfinite is incorrect.

Revert "[DebugInfo] Add new instruction and DIExpression operator for variadic debug values"

This reverts commit d07f106f4a48b6e941266525b6f7177834d7b74e.

[DebugInfo] Add new instruction and DIExpression operator for variadic debug values

This patch adds a new instruction that can represent variadic debug values,
DBG_VALUE_VAR. This patch alone covers the addition of the instruction and a set
of basic code changes in MachineInstr and a few adjacent areas, but does not
correctly handle variadic debug values outside of these areas, nor does it
generate them at any point.

The new instruction is similar to the existing DBG_VALUE instruction, with the
following differences: the operands are in a different order, any number of
values may be used in the instruction following the Variable and Expression
operands (these are referred to in code as “debug operands”) and are indexed
from 0 so that getDebugOperand(X) == getOperand(X+2), and the Expression in a
DBG_VALUE_VAR must use the DW_OP_LLVM_arg operator to pass arguments into the
expression.

The new DW_OP_LLVM_arg operator is only valid in expressions appearing in a
DBG_VALUE_VAR; it takes a single argument and pushes the debug operand at the
index given by the argument onto the Expression stack. For example the
sub-expression `DW_OP_LLVM_arg, 0` has the meaning “Push the debug operand at
index 0 onto the expression stack.”

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

[llvm-objcopy][llvm-strip][test] Improve testing

This patch adds a number of new test cases that cover various
llvm-objcopy and llvm-strip features that had missing test coverage of
various descriptions:
* --add-section - checked the shdr properties, not just the content.
* Dedicated test case for --add-symbol when there are many sections.
* Show that --change-start accepts negative values without overflow.
  This was previously present but got lost between review versions.
* --dump-section - show that multiple sections can be dumped
  simultaneously to different files, and that an error is reported when
  a section cannot be found.
* --globalize-symbol(s) - show that symbols that are not mentioned are
  not globalized, if they would otherwise be, and that missing symbols
  from the list do not cause problems.
* --keep-global-symbol - show that the --regex option can be used in
  conjunction with this option.
* --keep-symbol - show that the --regex option can be used in
  conjunction with this option.
* --localize-symbol(s) - show that symbols that are not mentioned are
  not localized, if they would otherwise be, and that missing symbols
  from the list do not cause problems.
* --prefix-alloc-sections - show the behaviour of an empty string
  argument and multiple arguments.
* --prefix-symbols - show the behaviour of an empty string argument and
  multiple arguments. Also show the option applies to undefined symbols.
* --redefine-symbol - show that symbols with no name can be renamed,
  that it is not an error if a symbol is not specified, and that the
  option doesn't chain (i.e. --redefine-sym a=b --redefine-sym b=c does
  not redefine a as c).
* --rename-section - show that all section flags are preserved if none
  are specified. Also show that the option does not chain.
* --set-section-alignment - show that only specified sections have
  their alignments changed.
* --set-section-flags - show which section flags are preserved when this
  option is used. Also show that unspecified sections are not affected.
* --preserve-dates - show that -p is an alias of --preserve-dates.
* --strip-symbol - show that --regex works with this option for
  llvm-objcopy as well as llvm-strip.
* --strip-unneeded-symbol(s) - show more clearly that needed symbols are
  not stripped even if requested by this option.
* --allow-broken-links - show the sh_link of a symbol table is set to 0
  when its string table has been removed when this option is specified.
* --weaken-symbol(s) - show that symbols that are not mentioned are not
  weakened, if they would otherwise be, and that missing symbols from
  the list do not cause problems.
* --wildcard - show the wildcard behaviour for several options that were
  previously unchecked.

Reviewed by: alexshap

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

Revert "[darwin] switch blocking mutex from osspinlock to os_unfair_lock"

> OSSpinLock is deprecated, so we are switching to `os_unfair_lock`. However, `os_unfair_lock` isn't available on older OSs, so we keep `OSSpinLock` as fallback.
>
> Also change runtime assumption check to static since they only ever check constant values.
>
> rdar://69588111
>
> Reviewed By: delcypher, yln
>
> Differential Revision: https://reviews.llvm.org/D97509

This reverts commit 71ef54337d5e83c6767e4816227ef340caa337fc.

[gn build] Port d791695cb517

[objdump][ARM] Use correct offset when printing ARM/Thumb branch targets

llvm-objdump only uses one MCInstrAnalysis object, so if ARM and Thumb
code is mixed in one object, or if an object is disassembled without
explicitly setting the triple to match the ISA used, then branch and
call targets will be printed incorrectly.

This could be fixed by creating two MCInstrAnalysis objects in
llvm-objdump, like we currently do for SubtargetInfo. However, I don't
think there's any reason we need two separate sub-classes of
MCInstrAnalysis, so instead these can be merged into one, and the ISA
determined by checking the opcode of the instruction.

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

[MCA] Add support for in-order CPUs

This patch adds a pipeline to support in-order CPUs such as ARM
Cortex-A55.

In-order pipeline implements a simplified version of Dispatch,
Scheduler and Execute stages as a single stage. Entry and Retire
stages are common for both in-order and out-of-order pipelines.

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

[X86] canonicalizeShuffleWithBinOps - handle general unaryshuffle(binop(x,c)) patterns not just xor(x,-1)

Generalize the shuffle(not(x)) -> not(shuffle(x)) fold to handle any binop with 0/-1.

Hopefully we can further generalize to help push target unary/binary shuffles through binops similar to what we do in DAGCombiner::visitVECTOR_SHUFFLE

[NFC] Fix typos in CallingConvLower.h

[llvm-objcopy][llvm-strip] Improve --discard-all documentation and help

The help text and documentation for the --discard-all option failed to
mention that the option also causes the removal of debug sections. This
change fixes both for both llvm-objcopy and llvm-strip.

Reviewed by: MaskRay

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

[llvm-objcopy/strip] Fix off-by-one error in SYMTAB_SHNDX need check

The check for whether an extended symbol index table was required
dropped the first SHN_LORESERVE sections from the sections array before
checking whether the remaining sections had symbols. Unfortunately, the
null section header is not present in this list, so the check was
skipping the first section that might be important. If that section
contained a symbol, and no subsequent ones did, the .symtab_shndx
section would not be emitted, leading to a corrupt object.

Also consolidate and expand test coverage in the area to cover this bug
and other aspects of the SYMTAB_SHNDX section.

Reviewed by: alexshap, MaskRay

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

[libcxx] Move Linaro AArch64 buildbots to buildkite

Reviewed By: #libc, ldionne

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

[clangd] Introduce client state invalidation

Clangd can invalidate client state of features like semantic higlighting
without client explicitly triggering, for example after a preamble build
caused by an onSave notification on a different file.

This patch introduces a mechanism to let client know of such actions,
and also calls the workspace/semanticTokens/refresh request to
demonstrate the situation after each preamble build.

Fixes https://github.com/clangd/clangd/issues/699.

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

[ARM] Remove new ARMSelectionDAGTest unittest.

This removes the unit test from a968e7b82eac as it reportedly causes
some link problems. It can be reinstated once the issues are understood
and sorted out.

[Polly][Codegen] Emit access group metadata.

Emit llvm.loop.parallel_accesses metadata instead of
llvm.mem.parallel_loop_access. The latter is deprecated because it
assumes that LoopIDs are persistent, which they are not.
We also emit parallel access metadata for all surrounding parallel
loops, not just the innermost parallel.

[mlir] ODS: change OpBuilderDAG to OpBuilder

We no longer have the non-DAG version.

Reviewed By: rriddle

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

[X86][CodeGenPrepare] Try to reuse IV's incremented value instead of adding the offset, part 2

This patch enables the case where we do not completely eliminate offset.
Supposedly in this case we reduce live range overlap that never harms, but
since there are doubts this is true, this goes as a separate change.

Differential Revision: https://reviews.llvm.org/D96399
Reviewed By: reames

[llvm-objcopy][test] Improve many-sections object and test case

Additionally do some test tidy-ups and improve coverage of symbol
section indexes where the logical section index >= SHN_LORESERVE.

The symbol and section names in the many-section input object were
mostly shared. This patch changes them to be distinct, enabling
different operations such as --add-symbol, to be more targeted, when
using the object. It also makes the test less confusing and removes some
oddness in the symbol table order, presumably caused by the duplicate
names.

The input object was built from assembly that was of the form:
.section s1
sym1:
.section s2
sym2:
...
with a total of 65536 such occurrences. llvm-objcopy was then used to
remove the empty .text section automatically generated by MC, and
incidentally to move .strtab to the end of the object. This ensured that
the section/symbol indexes matched their name (i.e. section index 1 was
s1, section index 2 was s2 etc, and sym1 was in s1, sym2 in s2 etc).

Reviewed by: MaskRay

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

[RISCV] Fix crash when inserting large fixed-length subvectors

This patch addresses a compiler crash resulting from passing a
fixed-length type to one that expects scalable vector types. An
assertion was added to prevent this regressing in the future.

Reviewed By: craig.topper

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

[RISCV] Preserve fixed-length VL on insert_vector_elt in more cases

This patch fixes up one case where the fixed-length-vector VL was
dropped (falling back to VLMAX) when inserting vector elements, as the
code would lower via ISD::INSERT_VECTOR_ELT (at index 0) which loses the
fixed-length vector information.

To this end, a custom node, VMV_S_XF_VL, was introduced to carry the VL
operand through to the final instruction. This node wraps the RVV
vmv.s.x and vmv.s.f instructions, which were being selected by
insert_vector_elt anyway.

There should be no observable difference in scalable-vector codegen.

There is still one outstanding drop from fixed-length VL to VLMAX, when
an i64 element is inserted into a vector on RV32; the splat (which is
custom legalized) has no notion of the original fixed-length vector
type.

Reviewed By: craig.topper

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

[ARM] Fix linking of the new unittest from a968e7b82eac

Revert "[XRay][x86_64] Fix CFI directives in assembly trampolines"

This reverts commit 9ee61cf3f67b9fdcee7c2dd650321264376bc0f2 since
it's failing to compile on Darwin.

[ARM] KnownBits for CSINC/CSNEG/CSINV

This adds some simple known bits handling for the three CSINC/NEG/INV
instructions. From the operands known bits we can compute the common
bits of the first operand and incremented/negated/inverted second
operand. The first, especially CSINC ZR, ZR, comes up fair amount in the
tests. The others are more rare so a unit test for them is added.

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

[lld][WebAssembly] -Bsymbolic creates indirect function table if needed

It can be that while processing relocations, we realize that in the end
we need an indirect function table.  Ensure that one is present, in that
case, to avoid writing invalid object files.

Fixes https://bugs.llvm.org/show_bug.cgi?id=49397.

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

[X86][CodeGenPrepare] Try to reuse IV's incremented value instead of adding the offset, part 1

While optimizing the memory instruction, we sometimes need to add
offset to the value of `IV`. We could avoid doing so if the `IV.next` is
already defined at the point of interest. In this case, we may get two
possible advantages from this:

- If the `IV` step happens to match with the offset, we don't need to add
  the offset at all;
- We reduce overlap of live ranges of `IV` and `IV.next`. They may stop overlapping
  and it will lead to better register allocation. Even if the overlap will preserve,
  we are not introducing a new overlap, so it should be a neutral transform (Disabled
  this patch, will come with follow-up).

Currently I've only added support for IVs that get decremented using `usub`
intrinsic. We could also support `AddInstr`, however there is some weird
interaction with some other transform that may lead to infinite compilation
in this case (seems like same transform is done and undone over and over).
I need to investigate why it happens, but generally we could do that too.

The first part only handles case where this reuse fully elimiates the offset.

Differential Revision: https://reviews.llvm.org/D96399
Reviewed By: reames

[LangRef] remove links to lifetime since use marker intro already has a link

[mlir] make implementations of translation to LLVM IR interfaces private

There is no need for the interface implementations to be exposed, opaque
registration functions are sufficient for all users, similarly to passes.

Reviewed By: mehdi_amini

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

[LangRef] fix more undefined label errors

[mlir] Add loop codegen options to some LLVM dialect ops.

Add a Loop Option attribute and generate llvm metadata attached to
branch instructions to control code generation.

Reviewed By: ftynse, mehdi_amini

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

[LegalizeVectorTypes] Remove a tautological compare.

[debugserver] Fix more compiler warnings on arm64

This fixes the following two warnings in code that's only compiled on
arm64:

 - warning: cast from 'const void *' to 'unsigned char *' drops const
   qualifier [-Wcast-qual]
 - warning: embedding a directive within macro arguments has undefined
   behavior [-Wembedded-directive]

[libcxx] Don't use dllimport for a static member in a template

This fixes clang warnings (that are treated as errors when running
the test suite):

libcxx/include/string:4409:59: error: definition of dllimport static field [-Werror,-Wdllimport-static-field-def]
               basic_string<_CharT, _Traits, _Allocator>::npos;

The warning is normally not visible as long as the libc++ headers
are treated as system headers.

The same construct is always an error in MSVC.

(One _LIBCPP_FUNC_VIS was added in
2d8f23f571635c1fb983b40c4c2548716a5b65b6, which broke DLL builds.
59919c4d6b6370da7133bbca0d31844e21646bb1 fixed this by adding another
_LIBCPP_FUNC_VIS on the declaration for consistency, but the underlying
issue remained, that one can't use dllimport here.)

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

[CSSPGO] Deduplicating dangling pseudo probes.

Same dangling probes are redundant since they all have the same semantic that is to rely on the counts inference tool to get reasonable count for the same original block. Therefore, there's no need to keep multiple copies of them. I've seen jump threading created tons of redundant dangling probes that slowed down the compiler dramatically. Other optimization passes can also result in redundant probes though without an observed impact so far.

This change removes block-wise redundant dangling probes specifically introduced by jump threading. To support removing redundant dangling probes caused by all other passes, a final function-wise deduplication is also added.

An 18% size win of the .pseudo_probe section was seen for SPEC2017. No performance difference was observed.

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

[CSSPGO] Unblocking optimizations by dangling pseudo probes.

This change fixes a couple places where the pseudo probe intrinsic blocks optimizations because they are not naturally removable. To unblock those optimizations, the blocking pseudo probes are moved out of the original blocks and tagged dangling, instead of allowing pseudo probes to be literally removed. The reason is that when the original block is removed, we won't be able to sample it. Instead of assigning it a zero weight, moving all its pseudo probes into another block and marking them dangling should allow the counts inference a chance to assign them a more reasonable weight. We have not seen counts quality degradation from our experiments.

The optimizations being unblocked are:

1. Removing conditional probes for if-converted branches. Conditional probes are tagged dangling when their homing branch arms are folded so that they will not be over-counted.
2. Unblocking jump threading from removing empty blocks. Pseudo probe prevents jump threading from removing logically empty blocks that only has one unconditional jump instructions.
3. Unblocking SimplifyCFG and MIR tail duplicate to thread empty blocks and blocks with redundant branch checks.

Since dangling probes are logically deleted, they should not consume any samples in LTO postLink. This can be achieved by setting their distribution factors to zero when dangled.

Reviewed By: wmi

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

[CSSPGO] Introducing dangling pseudo probes.

Dangling probes are the probes associated to an empty block. This usually happens when all real instructions are optimized away from the block. There is a problem with dangling probes during the offline counts processing. The way the sample profiler works is that samples collected on the first physical instruction following a probe will be counted towards the probe. This logically equals to treating the instruction next to a probe as if it is from the same block of the probe. In the dangling probe case, the real instruction following a dangling probe actually starts a new block, and samples collected on the new block may cause issues when counted towards the empty block.

To mitigate this issue, we first try to move around a dangling probe inside its owning block. If there are still native instructions preceding the probe in the same block, we can then use them as a place holder to collect samples for the probe. A pass is added to walk each block backwards looking for probes not followed by any real instruction and moving them before the first real instruction. This is done right before the object emission.

If we are unlucky to find such in-block preceding instructions for a probe, the solution we are taking is to tag such probe as dangling so that the samples reported for them will not be trusted by the compiler. We leave it up to the counts inference algorithm to get such probes a reasonable count. The number `UINT64_MAX` is used to mark sample count as collected for a dangling probe.

Reviewed By: wmi

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

[libcxx] adds concept `std::assignable_from`

Implements parts of:
    - P0898R3 Standard Library Concepts
    - P1754 Rename concepts to standard_case for C++20, while we still can

Depends on D96660

Reviewed By: ldionne, #libc

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

[Docs] Remove `no-aa` from the alias analysis documentation

The `no-aa` pass has been removed with 7b560d40bddf.

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

[Attributor] Make DepClass a required argument

We often used a sub-optimal dependence class in the past because we
didn't see the argument. Let's make it explicit so we remember to think
about it.

[Attributor] Fold "TrackDependence" into the DepClassTy enum

We don't need a bool and an enum to express the three options we
currently have. This makes the interface nicer and much easier to
use optional dependencies. Also avoids mistakes where the bool is
false and enum ignored.

[Attributor] Avoid work for GEPs and wait till the users are visited

[Attributor] Use known alignment as lower bound to avoid work

If we know already more than available from a use, we don't need to
invest time on it.

[Attributor][NFC] Move some trivial checks up

[Attributor] Use sensible initialization in AANoCaptureCallSiteReturned

[doc] Fix description of _Float16

According to ISO/IEC TS 18661-3:2015 _FloatN is interchange floating
point type, extended floating-point type is _FloatNx.

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2342.pdf

Reviewed By: SjoerdMeijer

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

[libc] Remove redundant header files included from internal paths.

[DSE] Add support for not aligned begin/end

This is an attempt to improve handling of partial overlaps in case of unaligned begin\end.

Existing implementation just bails out if it encounters such cases. Even when it doesn't I believe existing code checking alignment constraints is not quite correct. It tries to ensure alignment of the "later" start/end offset while should be preserving relative alignment between earlier and later start/end.

The idea behind the change is simple. When start/end is not aligned as we wish instead of bailing out let's adjust it as necessary to get desired alignment.

I'll update with performance results as measured by the test-suite...it's still running...

Reviewed By: fhahn

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

libclc: Add clspv target to libclc

Add clspv as a new target for libclc. clspv is an open-source compiler that compiles OpenCL C to Vulkan SPIR-V. Compiles for the spir target.

The clspv target differs from the the spirv target in the following ways:
* fma is modified to use uint2 instead of ulong for mantissas. This results in lower performance fma, but provides a implementation that can be used on more Vulkan devices where 64-bit integer support is less common.
* Use of a software implementation of nextafter because the generic implementation depends on nextafter being a defined builtin function for which clspv has no definition.
* Full optimization of the library (-O3) and no conversion to SPIR-V

This library is close to what would be produced by running opt -O3 < builtins.opt.spirv-mesa3d-.bc > builtins.opt.clspv--.bc and continuing the build from that point.

Reviewer: jvesely

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

[compiler-rt | interceptors] Provide an intercept override knob.

This knob is useful for downstream users who want that some of their
libc functions to not be intercepted.

Reviewed By: eugenis

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

[libcxx] adds concept `std::common_with`

Implements parts of:
    - P0898R3 Standard Library Concepts
    - P1754 Rename concepts to standard_case for C++20, while we still can

Depends on D96660

Reviewed By: ldionne, #libc

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

[InstCombine] Move statepoint intrinsic handling from visitCall to visitCallBase

statepoint intrinsic can be used in invoke context,
so it should be handled in visitCallBase to cover both call and invoke.

Reviewers: reames, dantrushin
Reviewed By: reames
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D97833

Add Windows ehcont section support (/guard:ehcont).

Add option /guard:ehcont

Reviewed By: rnk

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

LanguageRuntime for 0th frame unwind, simplify getting pc-for-symbolication

Add calls into LanguageRuntime when finding the unwind method to
use out of the 0th (currently executing) stack frame.

Allow for the LanguageRuntimes to indicate if this stack frames
should be treated like a zeroth-frame -- symbolication should be
done based on the saved pc address, not decremented like normal ABI
function calls.

Add methods to RegisterContext and StackFrame to get a pc value
suitable for symbolication, to reduce the number of places in lldb
where we decrement the saved pc values before symbolication.

<rdar://problem/70398009>
Differential Revision: https://reviews.llvm.org/D97644

[libc++] Introduce __identity_t<T>. NFCI.

This is just a shorter synonym for `__identity<T>::type`.
Use it consistently throughout, where possible.

There is still some metaprogramming in <memory> and <variant>
where `__identity` is being used _without_ immediately calling
`::type` on it; but this is the unusual case, and it will become
even less usual as we start deliberately protecting certain types
against deduction (e.g. D97742).

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

[libcxx] adds concept `std::common_reference_with`

Implements parts of:
    - P0898R3 Standard Library Concepts
    - P1754 Rename concepts to standard_case for C++20, while we still can

Depends on D96657

Reviewed By: ldionne, Mordante, #libc

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

[mlir][sparse] fix bug in reduction chain

Found with exhaustive testing, it is possible that a while loop
appears in between chainable for loops. As long as we don't
scalarize reductions in while loops, this means we need to
terminate the chain at the while. This also refactors the
reduction code into more readable helper methods.

Reviewed By: bixia

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

[LangRef] fix undefined label

[LangRef] Make lifetime intrinsic's semantics consistent with StackColoring's comment

This patch is an update to LangRef by describing lifetime intrinsics' behavior
by following the description of MIR's LIFETIME_START/LIFETIME_END markers
at StackColoring.cpp (https://github.com/llvm/llvm-project/blob/eb44682d671d66e422b02595a636050582a4d84a/llvm/lib/CodeGen/StackColoring.cpp#L163) and the discussion in llvm-dev.

In order to explicitly define the meaning of an object lifetime, I added 'Object Lifetime' subsection.

Reviewed By: nlopes

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

[mlir] Add support for generating Attribute classes for ODS

The support for attributes closely maps that of Types (basically 1-1) given that Attributes are defined in exactly the same way as Types. All of the current ODS TypeDef classes get an Attr equivalent. The generation of the attribute classes themselves share the same generator as types.

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

[RISCV] Make use of the required features in BuiltinInfo to store that V extension builtins require 'experimental-v'.

Use that to print the diagnostic in SemaChecking instead of
listing all of the builtins in a switch.

With the required features, IR generation will also be able
to error on this. Checking this here allows us to have a RISCV
focused error message.

Reviewed By: HsiangKai

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

[IRSymTab] Set FB_used on llvm.compiler.used symbols

IR symbol table does not parse inline asm. A symbol only referenced by inline
asm is not in the IR symbol table, so LTO does not know that the definition (in
another translation unit) is referenced and may internalize it, even if that
definition has `__attribute__((used))` (which lowers to `llvm.compiler.used` on
ELF targets since D97446).

```
// cabac.c
__attribute__((used)) const uint8_t ff_h264_cabac_tables[...] = {...};

// h264_cabac.c
  asm("lea ff_h264_cabac_tables(%rip), %0" : ...);
```

`__attribute__((used))` is the recommended way to tell the compiler there may
be inline asm references, so the usage is perfectly fine. This patch
conservatively sets the `FB_used` bit on `llvm.compiler.used` symbols to work
around the IR symbol table limitation. Note: before D97446, Clang never emitted
symbols in the `llvm.compiler.used` list, so this change does not punish any
Clang emitted global object.

Without the patch, `ff_h264_cabac_tables` may be assigned to a non-external
partition and get internalized. Then we will get a linker error because the
`cabac.c` definition is not exposed.

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

[AIX] Update default arch on AIX

On AIX, the default arch level should match the minimum supported arch level of the OS version.

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

[mlir][pdl][NFC] Rename InputOp to OperandOp

This better matches the actual IR concept that is being modeled, and is consistent with how the rest of PDL is structured.

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

[mlir][pdl] Add a new !pdl.range<> type

This type represents a range of positional values. It will be used in followup revisions to add support for variadic constructs to PDL, such as operand and result ranges.

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

[LICM][Coroutine] Don't sink stores from loops with coro.suspend instructions

See pr46990(https://bugs.llvm.org/show_bug.cgi?id=46990). LICM should not sink store instructions to loop exit blocks which cross coro.suspend intrinsics. This breaks semantic of coro.suspend intrinsic which return to caller directly. Also this leads to use-after-free if the coroutine is freed before control returns to the caller in multithread environment.

This patch disable promotion by check whether loop contains coro.suspend intrinsics.
This is a resubmit of D86190.
Disabling LICM for loops with coroutine suspension is a better option not only for correctness purpose but also for performance purpose.
In most cases LICM sinks memory operations. In the case of coroutine, sinking memory operation out of the loop does not improve performance since coroutien needs to get data from the frame anyway. In fact LICM would hurt coroutine performance since it adds more entries to the frame.

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

[test] Fix profiling.ll

`__llvm_prf_nm` is compressed if zlib is available. In addition, its size may not be that stable.

Add the use of register r for outlined function when register r is live in and defined later.

The compiler needs to mark register $x0 as live in for the following case.

    $x1 = ADDXri $sp, 16, 0
    BL @spam, csr_darwin_aarch64_aapcs, implicit-def dead $lr, implicit $sp, implicit $x0, implicit killed $x1, implicit-def $sp, implicit-def dead $x0

Reviewed By: paquette

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

Fix flang build after D97804

[dfsan] Remove hard-coded shadow width in more tests

As a preparation step for fast8 support, we need to update the tests
to pass in both modes. That requires generalizing the shadow width
and remove any hard coded references that assume it's always 2 bytes.

Reviewed By: stephan.yichao.zhao

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

[lld-link] Add safe icf mode to lld-link, which does safe icf for all sections.

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

[mlir][IR] Refactor the internal implementation of Value

The current implementation of Value involves a pointer int pair with several different kinds of owners, i.e. BlockArgumentImpl*, Operation *, TrailingOpResult*. This design arose from the desire to save memory overhead for operations that have a very small number of results (generally 0-2). There are, unfortunately, many problematic aspects of the current implementation that make Values difficult to work with or just inefficient.

Operation result types are stored as a separate array on the Operation. This is very inefficient for many reasons: we use TupleType for multiple results, which can lead to huge amounts of memory usage if multi-result operations change types frequently(they do). It also means that simple methods like Value::getType/Value::setType now require complex logic to get to the desired type.

Value only has one pointer bit free, severely limiting the ability to use it in things like PointerUnion/PointerIntPair. Given that we store the kind of a Value along with the "owner" pointer, we only leave one bit free for users of Value. This creates situations where we end up nesting PointerUnions to be able to use Value in one.

As noted above, most of the methods in Value need to branch on at least 3 different cases which is both inefficient, possibly error prone, and verbose. The current storage of results also creates problems for utilities like ValueRange/TypeRange, which want to efficiently store base pointers to ranges (of which Operation* isn't really useful as one).

This revision greatly simplifies the implementation of Value by the introduction of a new ValueImpl class. This class contains all of the state shared between all of the various derived value classes; i.e. the use list, the type, and the kind. This shared implementation class provides several large benefits:

* Most of the methods on value are now branchless, and often one-liners.

* The "kind" of the value is now stored in ValueImpl instead of Value
This frees up all of Value's pointer bits, allowing for users to take full advantage of PointerUnion/PointerIntPair/etc. It also allows for storing more operation results as "inline", 6 now instead of 2, freeing up 1 word per new inline result.

* Operation result types are now stored in the result, instead of a side array
This drops the size of zero-result operations by 1 word. It also removes the memory crushing use of TupleType for operations results (which could lead up to hundreds of megabytes of "dead" TupleTypes in the context). This also allowed restructured ValueRange, making it simpler and one word smaller.

This revision does come with two conceptual downsides:
* Operation::getResultTypes no longer returns an ArrayRef<Type>
This conceptually makes some usages slower, as the iterator increment is slightly more complex.
* OpResult::getOwner is slightly more expensive, as it now requires a little bit of arithmetic

From profiling, neither of the conceptual downsides have resulted in any perceivable hit to performance. Given the advantages of the new design, most compiles are slightly faster.

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

[lld-macho] Fix test breakage introduced by D97799