Fix a typo in the internals manual

[RISCV] Remove ForceTailAgnostic flag from vmv.s.x, vfmv.s.f and reductions.

In 0.9 these were defined to leave elements other than 0 in the
destination unmodified. They were changed to use the tail policy
in 0.10. I missed that update.

I assume no one has noticed because in order cores treat tail
agnostic the same as tail undisturbed. I believe Spike and QEMU do
the same.

Reviewed By: arcbbb, frasercrmck

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

[ELF] Add a GRP_COMDAT test with a local signature symbol

See https://groups.google.com/g/generic-abi/c/2X6mR-s2zoc

Test that a local signature symbol does not suppress COMDAT deduplication.

[MLIR] Remove LLVM_AnyInteger type constraint

LLVM Dialect uses builtin-integer types. The existing LLVM_AnyInteger
type constraint is a dupe of AnyInteger. This patch removes LLVM_AnyInteger
and replaces all usage with AnyInteger.

Reviewed By: ftynse

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

[libc++] NFC: Add regression tests for some <tuple> PRs that have been fixed

[clang-cl] Parse the /external: flags (PR36003)

They are still unsupported, but at least this makes clang-cl not mistake
them for being filenames.

As pointed out in the bug, VS 16.10 now uses these flags in new projects
by default.

Revert "[IR] make -stack-alignment= into a module attr"

This reverts commit 433c8d950cb3a1fa0977355ce0367e8c763a3f13.

Breaks the MIPS build.

[MLIR][MemRef] Only allow fold of cast for the pointer operand, not the value

Currently canonicalizations of a store and a cast try to fold all casts into the store.

In the case where the operand being stored is itself a cast, this is illegal as the type of the value being stored
will change. This PR fixes this by not checking the value for folding with a cast.

Depends on https://reviews.llvm.org/D103828

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

.clang-tidy: Disable misc-no-recursion in general/across the monorepo

[IR] make -stack-alignment= into a module attr

Similar to D102742, specifying the stack alignment via CodegenOpts means
that this flag gets dropped during LTO, unless the command line is
re-specified as a plugin opt. Instead, encode this information as a
module level attribute so that we don't have to expose this llvm
internal flag when linking the Linux kernel with LTO.

Looks like external dependencies might need a fix:
* https://github.com/llvm-hs/llvm-hs/issues/345
* https://github.com/halide/Halide/issues/6079

Link: https://github.com/ClangBuiltLinux/linux/issues/1377
Reviewed By: tejohnson

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

NFC: .clang-tidy: Inherit configs from parents to improve maintainability

In the interests of disabling misc-no-recursion across LLVM (this seems
like a stylistic choice that is not consistent with LLVM's
style/development approach) this NFC preliminary change adjusts all the
.clang-tidy files to inherit from their parents as much as possible.

This change specifically preserves all the quirks of the current configs
in order to make it easier to review as NFC.

I validatad the change is NFC as follows:

for X in `cat ../files.txt`;
do
  mkdir -p ../tmp/$(dirname $X)
  touch $(dirname $X)/blaikie.cpp
  clang-tidy -dump-config $(dirname $X)/blaikie.cpp > ../tmp/$(dirname $X)/after
  rm $(dirname $X)/blaikie.cpp
done

(similarly for the "before" state, without this patch applied)

for X in `cat ../files.txt`;
do
  echo $X
  diff \
    ../tmp/$(dirname $X)/before \
    <(cat ../tmp/$(dirname $X)/after \
      | sed -e "s/,readability-identifier-naming\(.*\),-readability-identifier-naming/\1/" \
      | sed -e "s/,-llvm-include-order\(.*\),llvm-include-order/\1/" \
      | sed -e "s/,-misc-no-recursion\(.*\),misc-no-recursion/\1/" \
      | sed -e "s/,-clang-diagnostic-\*\(.*\),clang-diagnostic-\*/\1/")
done

(using sed to strip some add/remove pairs to reduce the diff and make it easier to read)

The resulting report is:
  .clang-tidy
  clang/.clang-tidy
  2c2
  < Checks:          'clang-diagnostic-*,clang-analyzer-*,-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,-misc-non-private-member-variables-in-classes,-readability-identifier-naming,-misc-no-recursion'
  ---
  > Checks:          'clang-diagnostic-*,clang-analyzer-*,-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,-misc-non-private-member-variables-in-classes,-misc-no-recursion'
  compiler-rt/.clang-tidy
  2c2
  < Checks:          'clang-diagnostic-*,clang-analyzer-*,-*,clang-diagnostic-*,llvm-*,-llvm-header-guard,misc-*,-misc-unused-parameters,-misc-non-private-member-variables-in-classes'
  ---
  > Checks:          'clang-diagnostic-*,clang-analyzer-*,-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,-misc-non-private-member-variables-in-classes,-llvm-header-guard'
  flang/.clang-tidy
  2c2
  < Checks:          'clang-diagnostic-*,clang-analyzer-*,-*,llvm-*,-llvm-include-order,misc-*,-misc-no-recursion,-misc-unused-parameters,-misc-non-private-member-variables-in-classes'
  ---
  > Checks:          'clang-diagnostic-*,clang-analyzer-*,-*,llvm-*,misc-*,-misc-unused-parameters,-misc-non-private-member-variables-in-classes,-llvm-include-order,-misc-no-recursion'
  flang/include/flang/Lower/.clang-tidy
  flang/include/flang/Optimizer/.clang-tidy
  flang/lib/Lower/.clang-tidy
  flang/lib/Optimizer/.clang-tidy
  lld/.clang-tidy
  lldb/.clang-tidy
  llvm/tools/split-file/.clang-tidy
  mlir/.clang-tidy

The `clang/.clang-tidy` change is a no-op, disabling an option that was never enabled.
The compiler-rt and flang changes are no-op reorderings of the same flags.

(side note, the .clang-tidy file in parallel-libs is broken and crashes
clang-tidy because it uses "lowerCase" as the style instead of "lower_case" -
so I'll deal with that separately)

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

[libc++] Remove the old HTML documentation

This commit finishes moving the <atomic> design documents to the RST
documentation and removes the old documentation. https://libcxx.llvm.org
is already pointing to the new documentation only now, so the removal of
the old documentation is really a NFC.

I went over the old documentation and I don't think we're leaving anything
important behind - I think everything important was mentionned in the RST
documentation anyway.

Revert "[Polly][Isl] Removing nullptr constructor from C++ bindings. NFC."

This reverts commit be5e2fc7bf781c7fc079943552ea1b519f45c815.

This introduced a building error for polly. https://lab.llvm.org/buildbot#builders/10/builds/4951

[DAG] foldShuffleOfConcatUndefs - ensure shuffles of upper (undef) subvector elements is undef (PR50609)

shuffle(concat(x,undef),concat(y,undef)) -> concat(shuffle(x,y),shuffle(x,y))

If the original shuffle references any of the upper (undef) subvector elements, ensure the split shuffle masks uses undef instead of an out-of-bounds value.

Fixes PR50609

[LoopNest] Fix Wdeprecated-copy warnings

error: definition of implicit copy constructor for 'LoopNest' is
deprecated because it has a user-declared copy assignment operator
[-Werror,-Wdeprecated-copy]
  LoopNest &operator=(const LoopNest &) = delete;

Reviewed By: Meinersbur

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

[CUDA][HIP] Fix store of vtbl in ctor

vtbl itself is in default global address space. When clang emits
ctor, it gets a pointer to the vtbl field based on the this pointer,
then stores vtbl to the pointer.

Since this pointer can point to any address space (e.g. an object
created in stack), this pointer points to default address space, therefore
the pointer to vtbl field in this object should also be in default
address space.

Currently, clang incorrectly casts the pointer to vtbl field in this object
to global address space. This caused assertions in backend.

This patch fixes that by removing the incorrect addr space cast.

Reviewed by: Artem Belevich

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

Fix missing header and namespace qualifier in ADT Sequence

[Polly][Isl] Removing nullptr constructor from C++ bindings. NFC.

[Polly][Isl] Removing nullptr constructor from C++ bindings. NFC.

This is part of an effort to reduce the differences between the custom C++ bindings used right now by polly in `lib/External/isl/include/isl/isl-noxceptions.h` and the official isl C++ interface.

Changes made:
 - Removed `std::nullptr_t` constructor from all the classes in the isl C++ bindings.
 - `isl-noexceptions.h` has been generated by this https://github.com/patacca/isl/commit/a7e00bea38f251a4bcf5c2c6ce5fa7ee5f661528

Reviewed By: Meinersbur

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

[llvm] Make Sequence reverse-iterable

This patch simplifies the implementation of Sequence and makes it compatible with llvm::reverse.
It exposes the reverse iterators through rbegin/rend which prevents a dangling reference in std::reverse_iterator::operator++().

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

Revert "3rd Reapply "[DebugInfo] Use variadic debug values to salvage BinOps and GEP instrs with non-const operands""

> This reapplies c0f3dfb9, which was reverted following the discovery of
> crashes on linux kernel and chromium builds - these issues have since
> been fixed, allowing this patch to re-land.

This reverts commit 36ec97f76ac0d8be76fb16ac521f55126766267d.

The change caused non-determinism in the compiler, see comments on the code
review at https://reviews.llvm.org/D91722.

Reverting to unbreak people's builds until that can be addressed.

This also reverts the follow-up "[DebugInfo] Limit the number of values
that may be referenced by a dbg.value" in
a0bd6105d80698c53ceaa64bbe6e3b7e7bbf99ee.

[MLIR] Mark additional builtin attr methods const

* Mark the following methods const:
  * `ArrayAttr::getAsRange`
  * `ArrayAttr::getAsValueRange`
  * `DictionaryAttr::getAs`
* Make `DictionarAttr::getAs` generic over the name class, such that
  `Identifier` and `StringRef` arguments get forwarded to the underlying
  call to `get`. (Made generic to avoid introducing a dependency on
  `include/mlir/IR/Identifier.h` as per the diff discussion.)

Reviewed By: rriddle

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

[VP] getDeclarationForParams

`VPIntrinsic::getDeclarationForParams` creates a vp intrinsic
declaration for parameters you want to call it with.  This is in
preparation of a new builder class that makes emitting vp intrinsic code
nearly as convenient as using a plain ir builder (aka `VectorBuilder`,
to be used by D99750).

Reviewed By: frasercrmck, craig.topper, vkmr

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

[NFC] Remove some include cycles

These files include themselves directly.

[VE][NFC] IRBuilder<> -> IRBuilderBase

VE's TTI broke with the switch from IRBuilder<> to IRBuilderBase.
Following that change to compile again.

[clang] p1099 using enum part 1

This adds support for p1099's 'using SCOPED_ENUM::MEMBER;'
functionality, bringing a member of an enumerator into the current
scope. The novel feature here, is that there need not be a class
hierarchical relationship between the current scope and the scope of
the SCOPED_ENUM. That's a new thing, the closest equivalent is a
typedef or alias declaration. But this means that
Sema::CheckUsingDeclQualifier needs adjustment. (a) one can't call it
until one knows the set of decls that are being referenced -- if
exactly one is an enumerator, we're in the new territory. Thus it
needs calling later in some cases. Also (b) there are two ways we hold
the set of such decls. During parsing (or instantiating a dependent
scope) we have a lookup result, and during instantiation we have a set
of shadow decls. Thus two optional arguments, at most one of which
should be non-null.

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

[LoopUnrollAndJam] Change LoopUnrollAndJamPass to LoopNest pass

This patch changes LoopUnrollAndJamPass from FunctionPass to LoopNest pass.
The next patch will utilize LoopNest to effectively handle loop nests.

Also, a crash problem on legacy pass manager is fixed.

Reviewed By: Whitney

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

[OpenMP][OMPD] Implementation of OMPD debugging library - libompd.

This is the first of seven patches that implements OMPD, a debugging interface to support debugging of OpenMP programs.
It contains support code required in "openmp/runtime" for OMPD implementation.

Reviewed By: @hbae
Differential Revision: https://reviews.llvm.org/D100181

[CostModel] Return an invalid cost for memory ops with unsupported types

Fixes getTypeConversion to return `TypeScalarizeScalableVector` when a scalable vector
type cannot be legalized by widening/splitting. When this is the method of legalization
found, getTypeLegalizationCost will return an Invalid cost.

The getMemoryOpCost, getMaskedMemoryOpCost & getGatherScatterOpCost functions already call
getTypeLegalizationCost and will now also return an Invalid cost for unsupported types.

Reviewed By: sdesmalen, david-arm

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

[OpenCL] Add memory_scope_all_devices

Add the `memory_scope_all_devices` enum value, which is restricted to
OpenCL 3.0 or newer and the `__opencl_c_atomic_scope_all_devices`
feature.  Also guard `memory_scope_all_svm_devices` accordingly, which
is already available in OpenCL 2.0.

The `__opencl_c_atomic_scope_all_devices` feature is header-only, so
set its define to 1 in `opencl-c-base.h`.  This is done
unconditionally at the moment, as the mechanism for disabling
header-only options hasn't been decided yet.

This patch only adds a negative test for now.  Ideally adding a CL3.0
run line to atomic-ops.cl should suffice as a positive test, but we
cannot do that yet until (at least) generic address spaces and program
scope variables are supported in OpenCL 3.0 mode.

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

[RISCV] Add a test case showing inefficient vector codegen

[InstCombine] Add instcombine fold for extractelement + splat for scalable vectors

This patch allows that scalable vector can also use the fold that already
exists for fixed vector, only when the lane index is lower than the minimum
number of elements of the vector.

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

OptBisect.cpp - remove unused include. NFCI.

StringRef.h is included in OptBisect.h and we have no uses of std::string.

[CostModel][X86] Improve AVX1/AVX2 truncation costs

Based off the worse case numbers generated by D103695, we were overestimating the cost of a number of vector truncations:

AVX2: v2i32->v2i8, v2i64->v2i16 + v4i64->v4i32
AVX1: v2i32->v2i8, v4i64->v4i16 + v16i16->v16i8

Once we have a working set of conversion costs, the intention is to cleanup the tables and use legalized types a lot more to reduce the number of entries we currently have.

MemCpyOptimizer.cpp - hasUndefContentsMSSA - Pass DataLayout by reference. NFCI.

ValueTrackingTest.cpp - Pass DataLayout by reference. NFCI.

NVPTXTargetLowering::LowerReturn - Pass DataLayout by reference. NFCI.

[LoopVectorize] Don't use strict reductions when reordering is allowed

If the `-enable-strict-reductions` flag is set to true, then currently we will
always choose to vectorize the loop with strict in-order reductions. This is
not necessary where we allow the reordering of FP operations, such as
when loop hints are passed via metadata.

This patch moves useOrderedReductions so that we can also check whether
loop hints allow reordering, in which case we should use the default
behaviour of vectorizing with unordered reductions.

Reviewed By: sdesmalen

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

[mlir] fix shared-libs build

[DAG] Allow isNullOrNullSplat to see truncated zeroes

This sets the AllowTruncation flag on isConstOrConstSplat in
isNullOrNullSplat, allowing it to see truncated constant zeroes on
architectures such as AArch64, where only a i32.i64 are legal. As a
truncation of 0 is always 0, this should always be valid, allowing some
extra folding to happen including some of the cases from D103755.

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

[clang] Apply MS ABI details on __builtin_ms_va_list on non-windows platforms on x86_64

This fixes inconsistencies in the ms_abi.c testcase.

Also add a couple cases of missing double pointers in the windows part
of the testcase; the outcome of building that testcase on windows hasn't
changed, but the previous form of the test was imprecise (checking
for "%[[STRUCT_FOO]]*" when clang actually generates "%[[STRUCT_FOO]]**"),
which still used to match.

Ideally this would share code with the native Windows case, but
X86_64ABIInfo and WinX86_64ABIInfo aren't superclasses/subclasses of
each other so it's impractical, and the code to share currently only
consists of a couple lines.

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

[mlir] support memref of memref in standard-to-llvm conversion

Now that memref supports arbitrary element types, add support for memref of
memref and make sure it is properly converted to the LLVM dialect. The type
support itself avoids adding the interface to the memref type itself similarly
to other built-in types. This allows the shape, and therefore byte size, of the
memref descriptor to remain a lowering aspect that is easier to customize and
evolve as opposed to sanctifying it in the data layout specification for the
memref type itself.

Factor out the code previously in a testing pass to live in a dedicated data
layout analysis and use that analysis in the conversion to compute the
allocation size for memref of memref. Other conversions will be ported
separately.

Depends On D103827

Reviewed By: rriddle

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

[mlir] Make MemRef element type extensible

Historically, MemRef only supported a restricted list of element types that
were known to be storable in memory. This is unnecessarily restrictive given
the open nature of MLIR's type system. Allow types to opt into being used as
MemRef elements by implementing a type interface. For now, the interface is
merely a declaration with no methods. Later, methods to query, e.g., the type
size or whether a type can alias elements of another type may be added.

Harden the "standard"-to-LLVM conversion against memrefs with non-builtin
types.

See https://llvm.discourse.group/t/rfc-memref-of-custom-types/3558.

Depends On D103826

Reviewed By: rriddle

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

[mlir] fix integer type mismatch in alloc conversion to LLVM

Some places in the alloc-like op conversion use the converted index type
whereas other places use the pointer-sized integer type, which may not be the
same. Consistently use the converted index type, similarly to other address
calculations.

Reviewed By: pifon2a

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

Revert "[mlir][ArmSVE] Add basic mask generation operations"

This reverts commit 392af6a78bb7dfb87a24ed66db598c1d09ac756b

[JITLink] Clarify LinkGraph::splitBlock contract in comment.

[lldb] Set return status to failed when adding a command error

There is a common pattern:
result.AppendError(...);
result.SetStatus(eReturnStatusFailed);

I found that some commands don't actually "fail" but only
print "error: ..." because the second line got missed.

This can cause you to miss a failed command when you're
using the Python interface during testing.
(and produce some confusing script results)

I did not find any place where you would want to add
an error without setting the return status, so just
set eReturnStatusFailed whenever you add an error to
a command result.

This change does not remove any of the now redundant
SetStatus. This should allow us to see if there are any
tests that have commands unexpectedly fail with this change.
(the test suite passes for me but I don't have access to all
the systems we cover so there could be some corner cases)

Some tests that failed on x86 and AArch64 have been modified
to work with the new behaviour.

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

[Demangle][Rust] Parse const backreferences

Reviewed By: dblaikie

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

[Demangle][Rust] Parse type backreferences

Reviewed By: dblaikie

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

[Demangle][Rust] Parse path backreferences

Reviewed By: dblaikie

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

[mlir][ArmSVE] Add basic mask generation operations

These `arm_sve.cmp` functions are needed to generate scalable vector
masks as long as scalable vectors are not part of the standard types.
Once in standard, these can be removed and `std.cmp` can be used
instead.

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

[analyzer]  [NFC] Implement a wrapper SValBuilder::getCastedMemRegionVal for similar functionality on region cast

Summary: Replaced code on region cast with a function-wrapper SValBuilder::getCastedMemRegionVal. This is a next step of code refining due to suggestions in D103319.

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

[Driver] Support libc++ in MSVC

This implements support for using libc++ headers and library in the MSVC
toolchain.  We only support libc++ that is a part of the toolchain, and
not headers installed elsewhere on the system.

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

[RISCV] Use 0 for Log2SEW for vle1/vse1 intrinsics to enable vsetvli optimization.

Missed in D103299.

[RISCV] Masked compares should use a tail agnostic policy.

Writes of a mask result are always tail agnostic.

Unfortunately, this seems to have made codegen worse. I can only
think this must be because the vsetvli was acting as some sort
of barrier that prevented some code movement in the scheduler.

Reviewed By: arcbbb

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

[RISCV] Use AVL Operand instead of GPR for tied mask pseudo for vwadd.wv and similar.

I mistakenly copied this from an older version of our internal
repo.

BPF: fix relocation types in lib/Object/RelocationResolver.cpp

Commit 6a2ea84600ba ("BPF: Add more relocation kinds")
added new relocations R_BPF_64_ABS64 and R_BPF_64_ABS32
for normal 64-bit and 32-bit data relocations.
This is to replace some of functionalities with
R_BPF_64_64 and R_BPF_64_32 so that new R_BPF_64_64
and R_BPF_64_32 semantics are for ld_imm64 and
call instructions only.

The BPF support in lib/Object/RelocationResolver.cpp
is used to perform normal data relocations for
the case like DWARFObjInMemory with an object file
(search function getRelocationResolver() in file
DebugInfo/DWARF/DWARFContext.cpp) or llvm-readobj
to dump ".stack_sizes" section data.
In all these casees, normal 64-bit and 32-bit relocations
are performed and such resolution resolution
is exactly what implemented in RelocationResolver.cpp.

But Commit 6a2ea84600ba missed to change
R_BPF_64_64/R_BPF_64_32 to R_BPF_64_ABS64/R_BPF_64_ABS32.
This patch fixed the issue and added a test for it
with llvm-readobj dumping ".stack_sizes" section.

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

[lld-macho] Implement -force_load_swift_libs

It causes libraries whose names start with "swift" to be force-loaded.
Note that unlike the more general `-force_load`, this flag only applies
to libraries specified via LC_LINKER_OPTIONS, and not those passed on
the command-line. This is what ld64 does.

Reviewed By: #lld-macho, thakis

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

[lld-macho] Implement cstring deduplication

Our implementation draws heavily from LLD-ELF's, which in turn delegates
its string deduplication to llvm-mc's StringTableBuilder. The messiness of
this diff is largely due to the fact that we've previously assumed that
all InputSections get concatenated together to form the output. This is
no longer true with CStringInputSections, which split their contents into
StringPieces. StringPieces are much more lightweight than InputSections,
which is important as we create a lot of them. They may also overlap in
the output, which makes it possible for strings to be tail-merged. In
fact, the initial version of this diff implemented tail merging, but
I've dropped it for reasons I'll explain later.

**Alignment Issues**

Mergeable cstring literals are found under the `__TEXT,__cstring`
section. In contrast to ELF, which puts strings that need different
alignments into different sections, clang's Mach-O backend puts them all
in one section. Strings that need to be aligned have the `.p2align`
directive emitted before them, which simply translates into zero padding
in the object file.

I *think* ld64 extracts the desired per-string alignment from this data
by preserving each string's offset from the last section-aligned
address. I'm not entirely certain since it doesn't seem consistent about
doing this; but perhaps this can be chalked up to cases where ld64 has
to deduplicate strings with different offset/alignment combos -- it
seems to pick one of their alignments to preserve. This doesn't seem
correct in general; we can in fact can induce ld64 to produce a crashing
binary just by linking in an additional object file that only contains
cstrings and no code. See PR50563 for details.

Moreover, this scheme seems rather inefficient: since unaligned and
aligned strings are all put in the same section, which has a single
alignment value, it doesn't seem possible to tell whether a given string
doesn't have any alignment requirements. Preserving offset+alignments
for strings that don't need it is wasteful.

In practice, the crashes seen so far seem to stem from x86_64 SIMD
operations on cstrings. X86_64 requires SIMD accesses to be
16-byte-aligned. So for now, I'm thinking of just aligning all strings
to 16 bytes on x86_64. This is indeed wasteful, but implementation-wise
it's simpler than preserving per-string alignment+offsets. It also
avoids the aforementioned crash after deduplication of
differently-aligned strings. Finally, the overhead is not huge: using
16-byte alignment (vs no alignment) is only a 0.5% size overhead when
linking chromium_framework.

With these alignment requirements, it doesn't make sense to attempt tail
merging -- most strings will not be eligible since their overlaps aren't
likely to start at a 16-byte boundary. Tail-merging (with alignment) for
chromium_framework only improves size by 0.3%.

It's worth noting that LLD-ELF only does tail merging at `-O2`. By
default (at `-O1`), it just deduplicates w/o tail merging. @thakis has
also mentioned that they saw it regress compressed size in some cases
and therefore turned it off. `ld64` does not seem to do tail merging at
all.

**Performance Numbers**

CString deduplication reduces chromium_framework from 250MB to 242MB, or
about a 3.2% reduction.

Numbers for linking chromium_framework on my 3.2 GHz 16-Core Intel Xeon W:

      N           Min           Max        Median           Avg        Stddev
  x  20          3.91          4.03         3.935          3.95   0.034641016
  +  20          3.99          4.14         4.015        4.0365     0.0492336
  Difference at 95.0% confidence
          0.0865 +/- 0.027245
          2.18987% +/- 0.689746%
          (Student's t, pooled s = 0.0425673)

As expected, cstring merging incurs some non-trivial overhead.

When passing `--no-literal-merge`, it seems that performance is the
same, i.e. the refactoring in this diff didn't cost us.

      N           Min           Max        Median           Avg        Stddev
  x  20          3.91          4.03         3.935          3.95   0.034641016
  +  20          3.89          4.02         3.935        3.9435   0.043197831
  No difference proven at 95.0% confidence

Reviewed By: #lld-macho, gkm

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

[yaml2obj] Fix buildbot-issue-4886

XCOFFEmitter.cpp:67:16: runtime error: null pointer passed as argument 2,
which is declared to never be null

[AMDGPU] Allow oversize vaddr in GFX10 MIMG assembly

As a follow up to D103672, we should allow vaddr to be larger than
required when assembling GFX10 MIMG instructions.

Reviewed By: dp

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

[AIX] Define __STDC_NO_ATOMICS__ and __STDC_NO_THREADS__

Revert/reapply to fix Git authorship metadata

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

Revert "[AIX] Define __STDC_NO_ATOMICS__ and __STDC_NO_THREADS__ predefined macros"

This reverts commit e6629be31e67190f0a524f009752d73410894560.

[AMDGPU] Add v5f32/VReg_160 support for MIMG instructions

Avoid having to round up to v8f32/VReg_256 when only 5 VGPRs are
required for a MIMG address operand.

Maintain _V8 instruction variants of pseudo instructions allowing
assembly prior to GFX10 to work as-is.  Currently the validator
can tell for GFX10 what the correct size is, so will disallow
oversize address registers.

Reviewed By: rampitec

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

[AIX] Define __STDC_NO_ATOMICS__ and __STDC_NO_THREADS__ predefined macros

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

[NFC][scudo] Print errno of fork failure

This fork fails sometime on sanitizer-x86_64-linux-qemu bot.

[RISCV] Use bitfields to shrink the size of the vector load/store intrinsics to pseudo instruction lookup tables.

[NFC][LSAN] Limit the number of concurrent threads is the test

Test still fails with D88184 reverted.

The test was flaky on https://bugs.chromium.org/p/chromium/issues/detail?id=1206745 and
https://lab.llvm.org/buildbot/#/builders/sanitizer-x86_64-linux

Reviewed By: morehouse

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

[dfsan] Add full fast8 support

Complete support for fast8:
- amend shadow size and mapping in runtime
- remove fast16 mode and -dfsan-fast-16-labels flag
- remove legacy mode and make fast8 mode the default
- remove dfsan-fast-8-labels flag
- remove functions in dfsan interface only applicable to legacy
- remove legacy-related instrumentation code and tests
- update documentation.

Reviewed By: stephan.yichao.zhao, browneee

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

[gn build] Port 692d7166f771

Revert "[libcxx][gardening] Move all algorithms into their own headers."

This reverts commit 7ed7d4ccb8991e2b5b95334b508f8cec2faee737 as it
uncovered a Clang bug PR50592.

Revert "[libcxx][module-map] creates submodules for private headers"

This reverts commit f1417eb9b1f51b689c78dd8cb0114c1749dd2845 as it
uncovered a Clang bug PR50592.

[RISCV] Optimize bitwise and with constant for the Zbs extension

This patch optimizes (and r i) to
(BCLRI (BCLRI r, i0), i1) in which i = ~((1<<i0) | (1<<i1)).
or
(BCLRI (ANDI r, i0), i1) in which i = i0 & ~(1<<i1).

Reviewed By: craig.topper

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

Revert "[TargetLowering] Only inspect attributes in the arguments for ArgListEntry"

Needs to be discussed more.

This reverts commit 255a5c1baa6020c009934b4fa342f9f6dbbcc46
This reverts commit df2056ff3730316f376f29d9986c9913b95ceb1
This reverts commit faff79b7ca144e505da6bc74aa2b2f7cffbbf23
This reverts commit d2a9020785c6e02afebc876aa2778fa64c5cafd

[RISCV] Store Log2 of EEW in the vector load/store intrinsic to pseudo lookup tables. NFCI

This uses 3 bits of data instead of 7. I'm wondering if we can use
bitfields for the lookup table key where this would matter.

I also name the shift_amount template to log2 since it is used
with more than just an srl now.

[AMDGPU] Handle constant LDS uses from different kernels

This allows to lower an LDS variable into a kernel structure
even if there is a constant expression used from different
kernels.

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

[AMDGPU] Introduce command line switch to control super aligning of LDS.

Reviewed By: rampitec

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

[IR] Add utility to convert constant expression operands (of an instruction) to instructions.

In the situation where we need to replace a constant operand C from a constant expression CE
by an instruction NI, it not possible without converting CE itself into an instruction. This
utility helps to convert the given set of constant expression operands from an instruction I
into a corresponding set of instructions.

The current use-case for this utility is from the patches - https://reviews.llvm.org/D103225
and https://reviews.llvm.org/D103655.

Reviewed By: rampitec

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

[SCEV] Properly guard reasoning about infinite loops being UB on mustprogress

Noticed via code inspection. We changed the semantics of the IR when we added mustprogress, and we appear to have not updated this location.

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

[BasicAA] Handle PHIs without incoming values gracefully

Fix a bug introduced by f6f6f6375d1a4bced8a6e79a78726ab32b8dd879.
Now for empty PHIs, instead of crashing on assert(hasVal()) in
Optional's internals, we'll return NoAlias, as we did before that patch.

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

[Test] Add a JumpThreading test exposing a bug in BasicAA.

Revert "[AArch64] handle -Wa,-march="

This reverts commit fd11a26d368c5a909fb88548fef2cee7a6c2c931.

[mlir-lsp-server] Fix bug in symbol use/def tracking

We were accidentally only using the first found reference, instead of all of them. This revision fixes this by properly tracking all references to a symbol.

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

[mlir-lsp-server] Add support for hover on symbol references

For now the hover simply shows the same information as hovering on the operation
name. If necessary this can be tweaked to something symbol specific later.

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

[mlir-lsp-server] Add support for hover on region operations

This revision adds support for hover on region operations, by temporarily removing the regions during printing. This revision also tweaks the hover format for operations to include symbol information, now that FuncOp can be shown in the hover.

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

[lld/mac] Add reexports after reexporter to inputFiles

When a library "host"'s reexports change their installName with
`$ld$os10.11$install_name$host`, we used to write a load command for "host" but
write the version numbers of the reexport instead of "host". This fixes that.

I first thought that the rule is to take the version numbers from the library
that originally had that install name (implemented in D103819), but that's not
what ld64 seems to be doing: It takes the version number from the first dylib
with that install name it loads, and it loads the reexporting library before
the reexports. We already did most of that, we just added reexports before the
reexporter. After this change, we add the reexporter before the reexports.

Addresses https://bugs.llvm.org/show_bug.cgi?id=49800#c11 part 1.

(ld64 seems to add reexports after processing _all_ files on the command line,
while we add them right after the reexporter. For the common case of reexport +
$ld$ symbol changing back to the exporter name, this doesn't make a difference,
but you can construct a case where it does. I expect this to not make a
difference in practice though.)

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

[ELF] getRelocatedSection: remove the check for ET_REL object file

getRelocatedSection interface should not check that the object file is
relocatable, as executable files may have relocations preserved with
`--emit-relocs` linker flag. The relocations are useful in context of post-link
binary analysis for function reference identification. For example, BOLT relies
on relocations to perform function reordering.

Reviewed By: MaskRay, jhenderson

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

[X32] Add Triple::isX32(), use it.

So far, support for x86_64-linux-gnux32 has been handled by explicit
comparisons of Triple.getEnvironment() to GNUX32. This worked as long as
x86_64-linux-gnux32 was the only X32 environment to worry about, but we
now have x86_64-linux-muslx32 as well. To support this, this change adds
an isX32() function and uses it. It replaces all checks for GNUX32 or
MuslX32 by isX32(), except for the following:

- Triple::isGNUEnvironment() and Triple::isMusl() are supposed to treat
  GNUX32 and MuslX32 differently.
- computeTargetTriple() needs to be able to transform triples to add or
  remove X32 from the environment and needs to map GNU to GNUX32, and
  Musl to MuslX32.
- getMultiarchTriple() completely lacks any Musl support and retains the
  explicit check for GNUX32 as it can only return x86_64-linux-gnux32.

Reviewed By: MaskRay

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

[clang] Fix reading long doubles with va_arg on x86_64 mingw

On x86_64 mingw, long doubles are always passed indirectly as
arguments (see an existing case in WinX86_64ABIInfo::classify);
generalize the existing code for reading varargs - any non-aggregate
type that is larger than 64 bits (which would be both long double
in mingw, and __int128) are passed indirectly too.

This makes reading varargs consistent with how they're passed,
fixing interop with both gcc and clang callers, for long double
and __int128.

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

[LoopUnroll] Clamp unroll count to MaxTripCount

Unrolling with more iterations than MaxTripCount is pointless, as
those iterations can never be executed. As such, we clamp ULO.Count
to MaxTripCount if it is known. This means we no longer need to
consider iterations after MaxTripCount for exit folding, and the
CompletelyUnroll flag becomes independent of ULO.TripCount.

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

[OpenMP][runtime] add .clang-tidy file

Use same checks as compiler-rt which removes checks for readability-*
and llvm-header style.

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

[OpenMP] libomp: implement OpenMP 5.1 inoutset task dependence type

Refactored code of dependence processing and added new inoutset dependence type.
Compiler can set dependence flag to 0x8 when call __kmpc_omp_task_with_deps.
Size of type of the dependence flag changed from 1 to 4 bytes in clang.
All dependence flags library gets so far and corresponding dependence types:
1 - IN, 2 - OUT, 3 - INOUT, 4 - MUTEXINOUTSET, 8 - INOUTSET.

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

AMDGPU: Move codegen test out of MIR test directory

This is testing an actual pass, not the MIR parser/printer.

GlobalISel: Use MMO helper for getting the size in bits

GlobalISel: Remove unnecessary .getReg(0)s

[SCEV] Compute exit counts for unsigned IVs using mustprogress semantics

The motivation here is simple loops with unsigned induction variables w/non-one steps. A toy example would be:
for (unsigned i = 0; i < N; i += 2) { body; }

Given C/C++ semantics, we do not get the nuw flag on the induction variable. Given that lack, we currently can't compute a bound for this loop. We can do better for many cases, depending on the contents of "body".

The basic intuition behind this patch is as follows:
* A step which evenly divides the iteration space must wrap through the same numbers repeatedly. And thus, we can ignore potential cornercases where we exit after the n-th wrap through uint32_max.
* Per C++ rules, infinite loops without side effects are UB. We already have code in SCEV which relies on this.  In LLVM, this is tied to the mustprogress attribute.

Together, these let us conclude that the trip count of this loop must come before unsigned overflow unless the body would form a well defined infinite loop.

A couple notes for those reading along:
* I reused the loop properties code which is overly conservative for this case. I may follow up in another patch to generalize it for the actual UB rules.
* We could cache the n(s/u)w facts. I left that out because doing a pre-patch which cached existing inference showed a lot of diffs I had trouble fully explaining. I plan to get back to this, but I don't want it on the critical path.

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

[MLIR][GPU] Simplify memcpy of cast

Introduce a simplification that allows memcpy of a cast to simply use the underlying op

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

[libc++] Rename 'and' to '&&'

[lld/mac] Add a test for -reexport_library + -dead_strip_dylibs

Our behavior here already matched ld64, now we have a test for it.

(ld64 even strips the library here if you also pass -needed_library bar.dylib.
That seems wrong to me, and lld honors needed_library in that case.)

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

[MLIR] Conditional Branch Argument Propagation

In an operation in the true/false dest of a branch,
one can assume that the operation itself was true/false if
only that edge can reach the operation.

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

[RISCV] Lower i8/i16 bswap/bitreverse to grevi/greviw with Zbp.

Include known bits support so we know we don't need to zext the
output if the input was already zero extended.

Reviewed By: luismarques

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